|
Home > Archive > Unix Programming > January 2004 > forking a thread
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Brian Raiter 2004-01-29, 11:34 am |
| I know that it's generally a bad idea for a thread in a multithreaded
processes to call fork(), at least under Linux 2.4. Is it still a bad
idea if the child process immediately calls exec()? How about if it
calls dup2() and then execs? If not, what are the problems?
Context: I have a threaded program, not of my own creation, in which
several threads (10-40) act as filters on a huge amount of data (over
1 GB). Currently this program is dependent on the data coming through
the pipes in sorted order. In order to remove this restriction, I'd
like each of these threads to fork off a /bin/sort process.
(Unfortunately, trying to fork off the proper number of sort proceses
before the first call to pthread_create() isn't feasible, not without
a huge rewrite. The idea here is to avoid doing major surgery on this
code, which is non-trivial and wholly uncommented.)
b
| |
| David Schwartz 2004-01-29, 2:35 pm |
|
"Brian Raiter" <blr@drizzle.com> wrote in message
news:bvc96v$h78$1@drizzle.com...
quote:
>I know that it's generally a bad idea for a thread in a multithreaded
> processes to call fork(), at least under Linux 2.4. Is it still a bad
> idea if the child process immediately calls exec()? How about if it
> calls dup2() and then execs? If not, what are the problems?
It should be just fine.
DS
|
|
|
|
|