[272] in Pthreads mailing list archive
Re: pthreads and fork()
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Tue Feb 20 16:04:14 1996
To: Samuel Tardieu <sam@inf.enst.fr>
Cc: pthreads@MIT.EDU
In-Reply-To: Your message of "20 Feb 1996 18:34:36 +0100."
<qw6enrpaok3.fsf@gargantua.enst.fr>
Date: Tue, 20 Feb 1996 15:26:38 EST
From: Christopher Provenzano <proven@MIT.EDU>
> >>>>> "Sam" == Samuel Tardieu <sam@inf.enst.fr> writes:
>
> Sam> How is fork() supposed to work with pthreads on Linux ? Is it
> Sam> supposed to work or is there anything else which should prevent
> Sam> it to do the right job ?
>
> I'll explain my question : a colleague of mine told me that the
> following program:
>
> =======
> main()
> {
> if (fork()==0) {
> printf("Child\n");
> sleep(5);
> printf("End of child\n");
> } else {
> printf("Father\n");
> sleep(5);
> printf("End of father\n");
> }
> }
> =======
>
> was never returning from the child process on Linux using a dynamic
> version of the pthreads library as bundled with the Linux GNAT
> distribution.
>
> Could people with Linux boxes test this simple program for me and send
> me a *private* mail (I'll summarize later, don't fill up the mailing
> list) with what it did and what pthreads release you used (and
> possibly what version of the Linux libc) ?
>
> Thanks in advance for your cooperation.
>
> Sam
>
> PS/ I'm interested even if you use a static version of the pthreads
> library.
> PPS/ The bug seems to occur only with the Linux version, I just tried
> with SunOS and 1.60b4_1 and it works fine.
> --
> "La cervelle des petits enfants, ca doit avoir comme un petit gout de noisett
> e"
> Charles Baudelaire
>
The sleep() call is deadlocking pthreads because pthreads assumes that
you are going to call exec() fairly soon after calling fork() (This is
also what POSIX assumes) and has turned off all scheduling operations.
Work is under way to make the behavior of fork() more reasonable by
tring to eliminate the scheduling deadlock problems but it is adviseable
to still call exec() shortly after calling fork() becuase the fork() call
will still only create a child process with the current thread running
as per the POSIX standard.
CAP
