what happens if

[Diego Iastrubni]

On יום שני 19 מרץ 2012 12:22:15 Erez D wrote:
> On Mon, Mar 19, 2012 at 12:20 PM, Nadav Har'El 
<nyh at math.technion.ac.il>wrote:
> > On Mon, Mar 19, 2012, Erez D wrote about "Re: what happens if":
> > > my reason for fork is only for exec() - to protect the first program
> > > from the other.
> > 
> > Then you should be all fine.

Another reason is for interacting with libraries which are "singleton". I had 
to work with a library to talk to some special HW. The library was designed to 
work with one device per process, and I needed to support "many".

I found myself "forking" and using pipe() to use the API from my main app. The 
problem is that that "fork()" was called from a thread. Read ahead.

> > If you're talking about the C language, you won't have any of these
> > problems. System calls like close() or dup() do not use any pthread
> > capabilities like mutexes.
> > 
> > If you're talking about a different programming language, I frankly
> > have no idea what its fork() does. Maybe you need to write some C
> > code that does fork()/exec() in one function call, and avoid this risk.
> 
> i will be using C++. are you sure this is safe ?

All theory I read before implementing this said this was a bad idea. The 
theory says that libc may maintain some mutex inside malloc() which is called 
from printf() for example. This means that even trivial things may kill your 
app. The theory says that in multithreaded applications as soon as you clone() 
(the system called used by pthread_create()) you should execvp.

In my application (a lot of C++, running on linux 2.6.32, glibc 2.9 and glibc 
2.11.1 on ARM) erverything worked perfectly against the theory, your mileage 
may vary.