Cool new Free software [LWN.net]

Cool new Free software

Posted Dec 19, 2012 19:48 UTC (Wed) by nix (subscriber, #2304) [Link]

Oh, there certainly can be 10k or more user events per second. Even ignoring the extreme case of network cards (10GbE cards can generate so many packets that you have only a clock tick or so to process each byte), mice can easily generate a few thousand events per second, and eye trackers will probably be even worse. I don't really want my CPU pegged because I waved my mouse around the screen -- not unless it's really got work to do, that is. Processing the mouse events is not work. (Note that if you're running X on a uniprocessor system this probably involves lots of context switches between multiple distinct processes, but even that is many many times faster than process creation.)

The softer version of fork() you refer to is called thread creation. It is faster -- I can generate a few tens of thousands of threads a second on this system -- but still not anywhere near as fast as context switching. You are still throwing performance away for, as far as I can tell, no benefit.

Worse yet -- if you're receiving a stream of events from some input device, they are almost certainly related in some way, and you almost always want to process them in the same process, or at least in related processes. Kicking off a new process for each event seems likely to lead to cursing from developers as they have to marshal the things back together again before they can process them. End result: a slower system, annoyed developers, more complex and buggy code, and... uh... no benefit, as far as I can see. What benefit is all this supposed to bring? Is it just 'more processes -> more isolation -> always necessarily better'? 'cos I used to think like that, and it just isn't so.

Cool new Free software

Posted Dec 19, 2012 20:46 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Of course not, spawning a new process for every event is not a good idea. I did not explain myself clearly and got confused in the meantime. Allow me to reboot the thread.

The thing is that an event should only do what it is supposed to do, and nothing else. If the result of a mouse movement is that a counter is updated, then let the kernel do it, and not bother my own process; when my process needs to read the counter it will do that. If the mouse pointer is moved and I want to paint a cool shadow, then ideally I would let the kernel know and the kernel will paint the cool shadow. Many things work like that now; it would be great if it was the default mechanism to answer user events. Look at it as dtrace on steroids, if you want.

For a long task (such as a menu selection), then by all means create a process and let it deal with the event. Otherwise, store the new value and let me query it if and when I need it. Taken to the extreme I don't even need to have running processes except for background tasks.

Cool new Free software

Posted Dec 19, 2012 22:50 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

Please try doing some GUI programming, your ideas sound good in the abstract, but they fail when you get down to trying to use them

Taking your mouse example, some graphics cards do support hardware mouse cursors, where the card handles moving the mouse pointer.

however, such support really doesn't help much and is fading from use today because nowdays people want to change the shape of the cursor depending on what you are doing, etc.

you also have to think about how the program should know that it should look for an update to the mouse position. you don't want it spinning in a loop when nothing happens.

you also don't just want the current position of the mouse, you want to know it's path, and how fast it's moving (along with what buttons, if any are pressed during any part of this time)

There are pretty good reasons that systems do things the way they do. People have tried a LOT of things over the years, and what's in place may not be the perfect way to do things, but they've survived lots of competing ideas along the way.

Cool new Free software

Posted Dec 19, 2012 23:03 UTC (Wed) by man_ls (subscriber, #15091) [Link]

I know this is just another load of armchair OS design, and that it will not probably work in real life, but perhaps it is worth a try for somebody.

Remember that this article refers to node.js. People have tried many things over the years in the web server arena, and around 2000 Apache was the clear market leader, with Microsoft a distant second. Apparently everything had been invented already. Then in 2002 a Russian guy decided to start development on a different model. Guess what: 10 years later it is the second web server in actives, ahead of Microsoft IIS. A year ago some crazy guys took Google's V8 engine and coded a web server around it, not in C or C++ but in... JavaScript. Preposterous. The result: the new web server everyone is talking about, capable of sustaining thousands of requests per second out of the box.

Cool new Free software

Posted Dec 20, 2012 12:53 UTC (Thu) by njs (guest, #40338) [Link]

There is no "the kernel" versus "the user process" when it comes to doing things -- there is just a CPU running some code, with different memory access rules. Presumably the way you would tell the kernel about this cool shadow and how to draw it is that you would provide some shadow drawing machine code, and then when the mouse pointer moved the kernel would set up some registers etc. (a "context") and then run this machine code. But now we have just described exactly what user processes are...

When a user process blocks, it doesn't actually sit there as an entity taking up space. It gets converted into a callback attached to whatever event caused it to block.