From: Justin Mason (jm at domain jmason.org)
Date: Sat 05 Feb 2000 - 16:52:49 GMT
allsop said:
> I'm working on developing a network server program at the moment, and I'd
> like to make it as stable and reliable as problem. So far, I've been
> messing around with threads, forks etc. Basically what I want to do is
> span a new thread to handle each new client connection. I'm using threads
> to handle this part. The problem is that I further want each thread to
> execute another seperate program, which the spawned thread can then
> control using signals or some other IPC. So far I'm planning on doing this
> using a fork from within the thread. The problem is that I'm a bit fuzzy
> on the overheads etc associated with threads, forks etc. So basically,
> what are the problems with architecture outlined above, and is there a
> 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.
Forking is slower than threads -- but threadsafe development itself
incurs a performance penalty, as locks are required around shared (or
possibly-shared) data structures.
But to answer the q you actually asked ;) -- you shouldn't have any
problem forking processes from within a subthread AFAIK.
--j.
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:05:21 GMT