| |||||||||||||
Cool new Free softwareCool new Free softwarePosted Dec 19, 2012 16:13 UTC (Wed) by nix (subscriber, #2304)In reply to: Cool new Free software by man_ls Parent article: Status.net service to phase out, replaced by pump.io
the kernel should drop its privileges and give control to the app's process directlyYou mean, exactly what select(), poll() et al do?
(Log in to post comments)
Cool new Free software Posted Dec 19, 2012 16:29 UTC (Wed) by man_ls (subscriber, #15091) [Link] I am not sure how select() and poll() work, but let me explain it a little bit better. With the classic model, a running process says that it wants to access e.g. the keyboard and then blocks on it: the whole process is frozen and its state is maintained. When an event comes, the kernel has to wake it up, thaw its state, and then let it run again where it left off.In a callback model, a process registers to access to the keyboard, its state is preserved (in javascript as a few closures), and the process dies. When an event comes a new process is created, the closures are recovered and off we go. The new process may even be based on the kernel process instead of the original, although in this hand-waving scenario I am not sure if this is at all feasible. Note that the new process can only access those variables that it is actually going to use, not the whole address space.
Cool new Free software Posted Dec 19, 2012 16:52 UTC (Wed) by nix (subscriber, #2304) [Link]
There is no such thing as 'a kernel process' in this sense: a process is not 'frozen' when it's select()ing, it's blocking *in the kernel*. When an event comes, the kernel wakes up and returns to userspace: no 'thawing' is necessary. select() is just a system call that blocks in the kernel, just like, say, read() often does (and just as lots of other syscalls do).
Creating a new process for every single event seems sure to be far more expensive than just a privilege transition out of kernel mode. My system here can manage about five or ten thousand forks per second, but it can manage well over a million context switches into and out of kernel mode per second.
(As for a process being 'based on' a kernel process, the level of your confusion regarding how processes work in Unix is seemingly so great that I can't even imagine what you intend this to mean. Your last line suggests that you expect it to have a whole new address space of its own, which makes the thing a process-creation-level of difficulty rather than a thread-creation-level, and requires among other things a TLB flush. Expensive, expensive...)
Cool new Free software Posted Dec 19, 2012 17:27 UTC (Wed) by man_ls (subscriber, #15091) [Link] I was just translating poorly what I imagine that node.js does, to kernel concepts (which for me is admittedly like translating French into Italian). Precisely the idea was to avoid creating a new address space. Instead of having a new address space, just use the kernel's (knowing that the process will not access what it shouldn't).
Cool new Free software Posted Dec 19, 2012 19:42 UTC (Wed) by nix (subscriber, #2304) [Link]
Yeah. That's exactly what select(), poll(), and other blocking syscalls do now, and have done since Unix was invented (well, OK, they weren't around then, but read() was, and it did just the same).
Cool new Free software Posted Dec 19, 2012 19:47 UTC (Wed) by man_ls (subscriber, #15091) [Link] Way to go then :) Thanks for your patience.
Cool new Free software Posted Dec 19, 2012 16:53 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Creating a new short-lived process for every mouse movement, joystick waggle, keystroke, and network packet sounds like the sort of thing that you need to have designed your kernel for from day one if it's to work remotely well.
Cool new Free software Posted Dec 19, 2012 17:31 UTC (Wed) by man_ls (subscriber, #15091) [Link] Yes, probably, but nix above says that his system can manage 10k fork()s per second, and I doubt there are that many user events. Also, I think a "softer" version of fork() should be used which does not create a new address space. If at all possible, it would be like the reverse of a micro-kernel: a macro-kernel which invokes stuff normally reserved to user space.To leave the hand-waving space, such a scheme might be possible in the OpenWebDevice or Boot2Gecko, where there is nothing between the kernel and the javascript VM.
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.
|
|||||||||||||