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.8 required=5.0 tests=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 9982321350 for ; Tue, 9 Apr 2024 03:45:10 +0200 (CEST) Received: from duke.felloff.net ([216.126.196.34]) by 9front; Mon Apr 8 21:43:58 -0400 2024 Message-ID: <6F9D9C74C3EB4F86B3BAA8B118C34967@felloff.net> Date: Tue, 09 Apr 2024 03:43:49 +0200 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: map/reduce blockchain ORM persistence-scale session optimizer Subject: Re: [9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7 Reply-To: 9front@9front.org Precedence: bulk > 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? yes, i thought about this delivering them as separate process sharing the same segments, tho it is too late, i have to sleep. i'll elaborate another time. tho interrupting one process is still something you need to support for canceling i/o's. no matter how you dress it. 9front has a "interrupt" ctl message in proc that only does the interruption without delivering a note for that. -- cinap