[ILUG] Threads, fork etc

[Mel]

On Sat, 5 Feb 2000, Justin Mason wrote:

> allsop said:
> 
> > I'm working on developing a network server program at the moment, and I'd
> > better way of doing it?
> 
> Do it UNIX-wise -- use fork(), and fork a process to handle each request
> if possible.  Threads are a big reliability sacrifice, for obvious
> reasons -- if you coredump in one thread, the whole comes
> down around your ears -- coredump in a process, and only that proc will
> die.
> 

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

> Forking is slower than threads -- but threadsafe development itself
> incurs a performance penalty, as locks are required around shared (or
> possibly-shared) data structures.
> 

yeah, but with locking in the right place, it's negliable. You can use
thread unique data to avoid collisions. With fork, you have to use shared
memory and semaphores which is even bigger

> 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.

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.

		Mel