[ILUG] Threads, fork etc

[Justin Mason]

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.