Cool new Free software

Posted Dec 19, 2012 20:46 UTC (Wed) by man_ls (guest, #15091)
In reply to: Cool new Free software by nix
Parent article: Status.net service to phase out, replaced by pump.io

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 (guest, #313) [Link] (1 responses)

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 (guest, #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 (subscriber, #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.