From: Justin Mason (jm at domain jmason.org)
Date: Wed 09 Feb 2000 - 12:00:15 GMT
Mel said:
> Depends on the size of the process. Fork is "heavier" than threading. I
> don't think you should expect your processes to be coredumping
> either. Threads have a speed advantage to fork depending on the thread
> implementation. Also bear in mind, that he might want the processes to
> share information
No, you're right, a process coredumping is *not* good. My POV on this
though is that software is never perfect, and occasionally you will
accidentally leave in bugs in a production version, that cause
coredumps/assertion failures/fatal errors... it'd be better not to bring
the lot crashing down at that point.
> > But to answer the q you actually asked ;) -- you shouldn't have any
> > problem forking processes from within a subthread AFAIK.
> oohhhhh. very messy. under POSIX, the new process only has one thread. If
> there is mutex's involved, it's very easy to deadlock and you have a right
> problem on your hand. You have to declare fork handlers before ou can fork
> safely and thats bothersome.
IIRC the original question was regarding whether it was OK to
fork-and-exec from within a thread to run a command -- I think *this* is
OK. As you point out, forking a multi-threaded process, and then
expecting to be able to use existing mutexes etc., is dangerous (and I'd
say unportable too!) but I think fork&exec is OK.
> back to the problem, if the sub processes need to share data, then thread
> - it's the way of the future. If the subprocesses are big, thread. In
> fact, it's only if each process is small, truely self contained and so on,
> is fork a better idea.
Another advantage of threading BTW is that it's portable to Win32 --
whereas fork isn't. Fork loses on that point!
I'm pretty down on threading, but it can definitely be useful --
especially if you need to communicate between the subprocesses/threads.
My personal preference is to design with fork() in mind; it can be
possible to "design out" some requirements for inter-thread/inter-process
communication.
I think both a fork-based / threads-based model should be catered for at
the design stage anyway; if you do that, you can make sure your choice of
concurrency strategy has a minimal performance impact, by designing the
IPC/locking/whatever strategies appropriately.
--j.
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:05:23 GMT