From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id C8AB9284D7 for ; Tue, 9 Apr 2024 01:33:09 +0200 (CEST) Received: from sendmail.purelymail.com ([34.202.193.197]) by 9front; Mon Apr 8 19:30:24 -0400 2024 DKIM-Signature: a=rsa-sha256; b=MA7du+xwFa1zdGQVi07lFcGIIusyXjtdnOszXJe0mHUSKM0dzPO/NL7UalZzVRWACL2yrstN/vopYQgP81kWI8Osf9uyW3rLe+S8W+xp8bcU6AeMqIo4cI4BByDzXr6NTnz6CkRfgFx74O0MEI7L9o9LCy3cidD3/NS1vr5UyKxMW0/XRXBpUSkXOSZ9ufep7y76uJ0kEvvLT/GrWsYRKXnJMBYQcGAFoDrNEzxJ7phd0cBEENAIZ5fs8yGiQ9/ajRpwvlQhV7uo3NUhrgWW2a4zsVclbDnkY2ohw6eRFa6w5p28xKnvH0wHxizSwXyMApbG0HjnRfvjF9Ir0z4cAw==; s=purelymail1; d=pbrane.org; v=1; bh=aMVfWAgFFniSEOUKRs36gXwh/E0heGj4IbnnxOCUU0M=; h=Received:From:To:Subject; DKIM-Signature: a=rsa-sha256; b=ksiCR4P0bxO3BfmHp4EWI0Hqwlx2+HB7d+fiXgQlvLsftWsRzPETybA4YAs4zDKKYVTxu7p0BwJBM4MjqmjH4sBEeFEzqQRSWjt++WFZLVt4J3cnhXC31nukOeVWcATtH5i5e3RPd+4Id6ibcS0TikdCiPMJKNIiu6LnEJwFtJIqcklrU24cySSVJk+IWFUcAByy2PvTDJMD1TKz+xPXWROQhdwFDHuyLjp0iwcY43cMMxCMrBs/4HP/7XayYPrbBlDC4iA+co6d7MyEUrMOZ4gqRKaxwMP6lNODkvwJ1CSrhnNs4b55p7O90giuLrTQbGS3EB5ixyPRiLZWYjAz9A==; s=purelymail1; d=purelymail.com; v=1; bh=aMVfWAgFFniSEOUKRs36gXwh/E0heGj4IbnnxOCUU0M=; h=Feedback-ID:Received:From:To:Subject; Feedback-ID: 10987:2443:null:purelymail X-Pm-Original-To: 9front@9front.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -860027839 for <9front@9front.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 08 Apr 2024 23:30:20 +0000 (UTC) Date: Mon, 8 Apr 2024 16:30:09 -0700 From: Anthony Martin To: 9front@9front.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: transactional webscale database standard-oriented layer Subject: [9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7 Reply-To: 9front@9front.org Precedence: bulk Perhaps I'm missing something but is it safe to call ready outside of the p->rlock? I thought it was a requirement for a Rendez to be kept around by other means if there is a possibility that it may be accessed by other proc. So isn't the Rendez on the stack in semacquire the actual problem? If I'm wrong, wouldn't it be easier to reason about if we used Richard Miller's solution (from the comment above wakeup)? The key change is to zero r->p immediately after saving it to p so the critical section involving r is just: lock(r) p = r->p r->p = nil unlock(r) What do you think? Cheers, Anthony P.S. As an aside, I really dislike procinterrupt (a.k.a postnote or swiproc). The asynchronous nature makes it difficult to reason about the invariants in sleep and wakeup. Has anyone experimented with alternative designs?