in reply to Using forks and threads

Being a recent adventurer into the "fork and thread jungle", I have to ask: What is it about your project that makes you want to do this? I had a concept that I wanted to use forking or threading with ("Swarming"), and it turned out horribly. My code ran many times slower with forking than without. I never tried threading because I heard from tye that it was as bad if not worse than forking.

So I ask again, why specifically do you want to do this?

---
It's all fine and dandy until someone has to look at the code.

Replies are listed 'Best First'.
Re^2: Using forks and threads
by ColinHorne (Sexton) on Jul 20, 2006 at 08:34 UTC
    Thanks for the reply. The reason I want to fork is because one thread needs to call system() (or pretend to by fork()ing and exec()ing itself).

    I'm expecting that calling system() from a thread would work fine most of the time, since the fork would duplicate all threads, etc, as expected, but would then exec() instantly after the fork. However, if this isn't atomic (eg: if the process received an interrupt just before exec()ing), one of the other threads might continue in the new fork before exec()ing, which certainly isn't what I'd want.

      Are you expecting this faux-system() call to take a long time? Do you care what it returns?

      ---
      It's all fine and dandy until someone has to look at the code.
        Potentially yes to both - it could well take a long time, and I'd like to check the error code, just in case. Although - would this make a difference? I'm guessing it's not a question of how long the child will run after the exec(), but how long after the fork() it takes to exec(), and if a different thread gets a chance to run (that is, assuming that forking on a unix-like system duplicates threads).