what happens if

[Erez D]

2012/3/19 Diego Iastrubni <elcuco at kde.org>

> 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.
>
what do you mean by " erverything worked perfectly against the theory" -
did it work or did you have problems although you just execvp after clone ?

>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20120320/7890c56d/attachment.html>