From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21187 invoked from network); 6 Jan 2021 19:30:42 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 6 Jan 2021 19:30:42 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Wed Jan 6 14:06:12 -0500 2021 Message-ID: <4FD99002DC7ADF798DF538CA33F26565@felloff.net> Date: Wed, 06 Jan 2021 20:05:50 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: stateless open AJAX component-based service Subject: Re: [9front] mycroftiv's zrv and rfork V, patch for current 9front Reply-To: 9front@9front.org Precedence: bulk this implementation seemes flawed to me. closesgrp() appears only to free the memory of the Srv* nodes, but doesnt actually free srv->chan, srv->owner and srv->name. also the locking seems suspicious. as the global Srv* list was just replaced with per process one, but we'r still only have a single srvlock to serialize concurrent access to it. so far, the srvgrp can only be reset or shared depending of the RFCSRVG flag. once you implement copying you'd need a lock per Sgrp. i'd prefer to have a lock per Sgrp right now and remove the global srvlock. pexit() should move the sgrp = up->sgrp; up->sgrp = nil in the exiting qlock(&up->debug);... block instead of making its own. why do we need /zrv? is there a new devzrv.c device that was missing in the diff? -- cinap