On Fre, 2011-08-19 at 15:57 -0400, Rich Felker wrote:
> On Fri, Aug 19, 2011 at 09:07:55AM +0200, Laurent Bercot wrote:
> > > One of the big reasons I now consider threads one of the best (but not
> > > always "the best", of course) approach to non-blocking operations is
> > > that they're the only idiom that allows one to mechanically transform
> > > blocking code into a non-blocking form.
> >
> > Multiprocessing does that too.
>
> Multiprocessing can accomplish *some* of the same things, but not all,
What does "multiprocessing" exactly mean?
> and it has a lot more troublesome corner cases and the transformation
> is not entirely mechanical or transparent. In particular:
>
> - A library can't fork new processes without the calling applicating
> being aware of this and tip-toeing around it. You have to make sure
> neither consumes the wait/exit status wanted by the other, and there
> can be only one (process-wide) SIGCHLD handler (not to mention
> signals are evil).
popen() is one prime example of this.
And, of course, it needs the library (or popen(), respectively)
designer/implementer needs to cope with this. And do not see any
significant problem with a sane implementation of popen().
And if the library is badly coded, just do not use it.
> - Unless you're sure you'll never use library code that uses threads,
> it's unsafe to keep the same program image after fork; you need to
> use exec. There are many reasons continuing in the child without
> calling exec may be dangerous if threads have been used, and
> although pthread_atfork was designed to address these issues, it
> suffers from unfixable conceptual flaws that make it nearly useless.
Well, that IMHO a clear and direct argument against threads (as such!).
Especially to use threads in some library which forces the application
to jump through God-knows-where just to use it.
> - Multi-process code must be able to handle the case where one or more
> of its processes terminates unexpectedly; restarting the terminated
> process can be nontrivial if the first process to discover it's
> missing is not the parent but one of its siblings or an unrelated
> process. Process ids are not meaningful except to the parent because
> there are race conditions where they can be reused. All of these
> issues disappear if you use threads instead, because (1) it's
> impossible to terminate a single thread; any asynchronous
> termination kills the whole process, and (2) there is no
> parent/child hierarchy among threads, and any thread in a process
> can join any joinable thread, not just ones it created.
>
> Note that just using threads does not commit you to making heavy use
> of memory sharing. You can still write your code very similar to how
Ooops, threads share the whole (virtual) memory by design.
> it would work with fork, except that all the ugly process handling
> goes away, and your program's commit charge requirements go down.
[...]
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
