On Wed, Mar 17, 2010 at 12:13:49PM +0100, Christophe Meessen <christo...@meessen.net> wrote: > My project is a CORBA like application with the difference that the > encoding is designed for stream oriented processing. It is thus a > middleware and the task to be performed is in general user defined. And > such a user defined task could be to compute a few thousand decimals of > Pi which will monopolize the CPU if not preempted.
Yes, or worse, it's a library that can block your whole process for seconds and cannot be event-ised (some database interfaces are like that). > Is there a way to have a pure single threaded EDSM model per CPU core > and still be able to cope with such type of use cases ? Well, in your example specifically, you actually *do* use your CPU, so from a cpu efficiency standpoint, it is optimal. More real-world is your app not doing number crunching but disk I/O or database lookups, and if you can't control those, you kind of have little choice than to use threads. > could a signal triggered by a timer be used to switch coroutines and > emulate a preemptive multithreaded system ? Yes (an example in perl: http://ue.tst.eu/a2499e8b0dc6c0bff8a6a33840344050.txt) But it is nasty. And slow: > I thought about this but it seemed like reinventing the wheel, so I gave > up and decided to rely on kernel developers to do things right. I would agree, before going down that road, use threads. Not the least because signal delivery is enourmously slow and eats any advantage (*). It would be nice if you could know in advance if a callback is doing "nasty" things (often, you cna mark a callback as being "fast" in such libraries - keeping the loop locked) and choose threads in that case only, that would be about ideal. So go for your leader/follower pattern. It's not trivial but I see no alternative to threads if you can't know what your callbacks do. (*) Not always true, as the Linux scheduler is kind of totally broken for years now (**), so explicit scheduling can often beat the kernel by a large factor, but that's not usually something that a taskset 1 cannot fix. (**) The loviest example I tried is running 5 burncpu programs on my quad core. This results in three busy cores and one core completely idling. Yeah. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
