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=1.1 required=5.0 tests=DATE_IN_PAST_03_06 autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 27348 invoked from network); 17 Apr 2021 09:09:51 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 17 Apr 2021 09:09:51 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Fri Apr 16 23:32:42 -0400 2021 Message-ID: <97F50E42E3F0E25822136DDBA369CECA@felloff.net> Date: Sat, 17 Apr 2021 05:32:31 +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: proven secure STM component Subject: Re: [9front] [patch] aux/wacom: prevent "no concurrent reads please" error when moving the pen too fast and support screen tilt Reply-To: 9front@9front.org Precedence: bulk > yeah, i was wondering if that was the motivation here, esp. my motivation to respond to this was the concern about wrapping pids. which is some area we actively spend time writing code to solve the issue. > in regards to minimizing user perceived latency. also think about reordering. when you spawn processes for each message, the oder of execution of them is not controllable, as the scheduler (on each cpu) is free to pick any to run next. > and if yes i'd be curious if it's actually significant enough to matter. it is just stupid. dont do stupid things. it doesnt make anything easier to spawn a process for every message. and you'r going to run into resource exhaustion problems as soon as theres anything blocking in the execution of these procs for any reason. any kind of unbounded forking can lead to problems. just like unbounded queues. everything might work fine in normal case... until the system experiences some kind of blockage and then collapses. > i can imagine high throughput scenarios, just not mouse input, where > this seems safe to assume even without measuring :D this has absolutely NOTHING todo with bandwidth. at all. the (process) switching and messaging overhead is always the same and something you cant get rid of. a fork takes the same amount of time no matter if you call your program "high bandwidth" or "low bandwidth". > On 4/15/21, cinap_lenrek@felloff.net wrote: >>> maybe we need to implement pid reusal... >> >> already done. wrapping pid's should not be a problem. >> >> the main concern is that creating and destroying processes >> has a cost compared to just wake up a existing process. -- cinap