Re: [9front] [patch] aux/wacom: prevent "no concurrent reads please" error when moving the pen too fast and support screen tilt

[cinap_lenrek@felloff.net]

> 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 <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