[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
Mika Nystrom
mika at async.caltech.edu
Tue Apr 19 17:29:24 CEST 2011
Never explained this clearly before. Thanks, Jay.
I suppose the reason CVSup forks and does work is to save copying
overhead because the two forked processes can share read-only pages
without any copying?
I remember that the last time I looked at this my reaction was "fork()
is not part of Modula-3 : people who use it are on their own". In a sense
this is still true as FreeBSD simply will not work with -pthread.
I'm afraid that, however, that removing -pthread didn't fix my Linux
lockup problems. Turns out the library I was having trouble with is
a PostgreSQL library written by Critical Mass. To fix it, I wrote a
program using m3tk and some Scheme code that will take any M3 interface
and wrap every routine in that interface in the following code structure:
PROCEDURE PQconnectPoll(VALUE conn : PQ.PGconn_star) : PQ.PostgresPollingStatusType =
BEGIN
SchedulerIndirection.DisableSwitching();
TRY
RETURN PQ.PQconnectPoll(conn)
FINALLY
SchedulerIndirection.EnableSwitching()
END
END PQconnectPoll;
which then gave rise to my previous bug report about BasicCTypes, which
m3tk cannot process a.t.m., owing to LONGINT breakage.
Also I have to call "SchedulerIndirection" since the routines to turn
off switching are named differently on CM3 (Scheduler.DisableSwitching)
and PM3 (SchedulerPosix.DisableSwitching).... this just seems gratuitous
to me but oh well I must have a dozen of these CM3/PM3 differences to deal
with, what's another one?
Mika
Jay K writes:
>--_9d99325a-59cc-496a-9b87-3881dbf2b655_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Previously: user threads: all threads survived fork()
>Previously: pthreads: only the thread calling fork() survived fork()
>Now: user threads and pthreads: only the thread calling fork() survives for=
>k()
>This must be how pthreads behave=2C and this makes user threads and pthread=
>s consistent.
>
>This change depends on pthread_atfork=2C for pthreads and user threads.
>It only really matters to the rare "fork + do more work" program=2C such as=
> cvsupd.
>Most programs either never fork=2C or exec almost immediately after fork.
>
>
>pthread_atfork offers a good model.
>A sort of "distributed" model.
>You don't have to go and change all the calls to fork().
>Each module with a need to do something before/after fork=2C calls the cent=
>ral pthread_atfork=2C
>and fork and pthread_atfork cooperate to do what is needed.
>
>
>No function pointer is needed.
>Instead move the code to m3core/thread.
>
>
>If you really must not use -pthread=2C then you must implement pthread_atfo=
>rk functionality
>yourself and have all fork() calls go through your own fork() wrapper that =
>cooperates
>with your pthread_atfork replacement.
>There is no free lunch -- there is a downside to this approach=2C as plain =
>fork() calls
>are ok and correct if pthread_atfork is used=2C but now become incorrect.
>Pick your poison:
> user thread/pthread inconsistency
> cvsupd incompatibility with pthreads=20
> user threads using pthread_atfork/-pthread=20
> fork() calls having to go through a wrapper (ok -- you could miss this an=
>d=20
> not likely notice -- only fork() calls in fork+do-more-work programs nee=
>d the wrapper).=20
>
>
>(Most of this has been explained multiple times=2C but people only pay atte=
>ntion
>when they think it affects them. I'm guilty of the same thing.)
>
>
> - Jay
>
>
>> To: jay.krell at cornell.edu
>> Date: Mon=2C 18 Apr 2011 19:30:58 -0700
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage=2C kernel 2.6.23=2C glib=
>c-2.6-4
>>=20
>>=20
>> If you or Tony could describe roughly what you think needs to be done
>> I'd be happy to look into it.
>>=20
>> The basic problem is that a decision that's made/described in
>> m3core/thread/m3makefile needs to someone find its way to controlling
>> what C code gets compiled elsewhere in the system. Or maybe there should
>> be an indirection into the thread library to pick up pthread_atfork (or n=
>ot).
>>=20
>> But then again you still haven't explained why you made the user threads =
>use
>> pthread_atfork. I just remove it from my installations=2C but then again=
> I'm
>> not trying to run CVSup so I don't know if it breaks that program to do s=
>o.
>>=20
>> Mika
>>=20
>> Jay K writes:
>> >--_3dd397d4-ac1d-4148-a9ff-059d27dd794a_
>> >Content-Type: text/plain=3B charset=3D"iso-8859-1"
>> >Content-Transfer-Encoding: quoted-printable
>> >
>> >
>> >> The following code from RTProcessC.c ensures that it is neeeded on eve=
>ry =3D
>> >Unix except
>> >> > /* NOTE: Even userthreads now depends
>> >> > * on availability of pthreads.
>> >> > * This can be fixed if need be.
>> >> > */
>> >
>> >=3D20
>> >Ok=3D2C "we" should probably go ahead and fix that.
>> >I'll try to=3D2C but no promises=3D2C sorry.
>> >=3D20
>> > - Jay
>> >=3D20
>> >> From: hosking at cs.purdue.edu
>> >> Date: Mon=3D2C 18 Apr 2011 18:11:26 -0400
>> >> To: mika at async.caltech.edu
>> >> CC: m3devel at elegosoft.com
>> >> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage=3D2C kernel 2.6.23=3D=
>2C glib=3D
>> >c-2.6-4
>> >>=3D20
>> >> Probably unnecessary=3D2C given that I think there is another entry po=
>int t=3D
>> >o forking a process (I forget where) in the thread-specific portion of m=
>3co=3D
>> >re. In which case the necessary work might be done there?
>> >>=3D20
>> >> On Apr 18=3D2C 2011=3D2C at 2:45 PM=3D2C Mika Nystrom wrote:
>> >>=3D20
>> >> > Tony Hosking writes:
>> >> > ...
>> >> >> pthread_atfork should not be needed under user threads.
>> >> > ...
>> >> >=3D20
>> >> > The following code from RTProcessC.c ensures that it is neeeded on e=
>ver=3D
>> >y Unix except
>> >> > FreeBSD before 6. The comment is from the checked-in source file.
>> >> >=3D20
>> >> > /* NOTE: Even userthreads now depends
>> >> > * on availability of pthreads.
>> >> > * This can be fixed if need be.
>> >> > */
>> >> >=3D20
>> >> > INTEGER
>> >> > __cdecl
>> >> > RTProcess__RegisterForkHandlers(
>> >> > ForkHandler prepare=3D2C
>> >> > ForkHandler parent=3D2C
>> >> > ForkHandler child)
>> >> > {
>> >> > /* FreeBSD < 6 lacks pthread_atfork. Would be good to use autoconf.
>> >> > * VMS lacks pthread_atfork? Would be good to use autoconf.
>> >> > * Win32 lacks pthread_atfork and fork. OK.
>> >> > *
>> >> > * As well=3D2C for all Posix systems=3D2C we could implement
>> >> > * atfork ourselves=3D2C as long as we provide a fork()
>> >> > * wrapper that code uses.
>> >> > */
>> >> > #if defined(_WIN32) \
>> >> > || defined(__vms) \
>> >> > || (defined(__FreeBSD__) /* && (__FreeBSD__ < 6)*/ )
>> >> > return 0=3D3B
>> >> > #else
>> >> > while (1)
>> >> > {
>> >> > int i =3D3D pthread_atfork(prepare=3D2C parent=3D2C child)=3D3B
>> >> > if (i !=3D3D EAGAIN)
>> >> > return i=3D3B
>> >> > sleep(0)=3D3B
>> >> > }
>> >> > #endif
>> >> > }
>> >>=3D20
>> > =3D
>> >
>> >--_3dd397d4-ac1d-4148-a9ff-059d27dd794a_
>> >Content-Type: text/html=3B charset=3D"iso-8859-1"
>> >Content-Transfer-Encoding: quoted-printable
>> >
>> ><html>
>> ><head>
>> ><style><!--
>> >.hmmessage P
>> >{
>> >margin:0px=3D3B
>> >padding:0px
>> >}
>> >body.hmmessage
>> >{
>> >font-size: 10pt=3D3B
>> >font-family:Tahoma
>> >}
>> >--></style>
>> ></head>
>> ><body class=3D3D'hmmessage'>
>> >>=3D3B The following code from RTProcessC.c ensures that it is neeeded=
> on e=3D
>> >very Unix except<BR>>=3D3B >=3D3B /* NOTE: Even userthreads now depe=
>nds<BR>=3D
>> >>=3D3B >=3D3B * on availability of pthreads.<BR>>=3D3B >=3D3B * =
>This can be=3D
>> > fixed if need be.<BR>>=3D3B >=3D3B */<BR><BR>
>> > =3D3B<BR>
>> >Ok=3D2C "we" should probably go ahead and fix that.<BR>
>> >I'll try to=3D2C but no =3D3Bpromises=3D2C sorry.<BR>
>> > =3D3B<BR>
>> > =3D3B- Jay<BR> =3D3B<BR>
>> >>=3D3B From: hosking at cs.purdue.edu<BR>>=3D3B Date: Mon=3D2C 18 Apr 2=
>011 18:11=3D
>> >:26 -0400<BR>>=3D3B To: mika at async.caltech.edu<BR>>=3D3B CC: m3devel=
>@elegos=3D
>> >oft.com<BR>>=3D3B Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage=3D2=
>C kerne=3D
>> >l 2.6.23=3D2C glibc-2.6-4<BR>>=3D3B <BR>>=3D3B Probably unnecessary=
>=3D2C given =3D
>> >that I think there is another entry point to forking a process (I forget=
> wh=3D
>> >ere) in the thread-specific portion of m3core. In which case the necessa=
>ry =3D
>> >work might be done there?<BR>>=3D3B <BR>>=3D3B On Apr 18=3D2C 2011=
>=3D2C at 2:45=3D
>> > PM=3D2C Mika Nystrom wrote:<BR>>=3D3B <BR>>=3D3B >=3D3B Tony Hosk=
>ing writes:=3D
>> ><BR>>=3D3B >=3D3B ...<BR>>=3D3B >=3D3B>=3D3B pthread_atfork sh=
>ould not be n=3D
>> >eeded under user threads.<BR>>=3D3B >=3D3B ...<BR>>=3D3B >=3D3B =
><BR>>=3D3B =3D
>> >>=3D3B The following code from RTProcessC.c ensures that it is neeeded=
> on e=3D
>> >very Unix except<BR>>=3D3B >=3D3B FreeBSD before 6. The comment is f=
>rom the=3D
>> > checked-in source file.<BR>>=3D3B >=3D3B <BR>>=3D3B >=3D3B /* N=
>OTE: Even u=3D
>> >serthreads now depends<BR>>=3D3B >=3D3B * on availability of pthread=
>s.<BR>&=3D
>> >gt=3D3B >=3D3B * This can be fixed if need be.<BR>>=3D3B >=3D3B */=
><BR>>=3D3B =3D
>> >>=3D3B <BR>>=3D3B >=3D3B INTEGER<BR>>=3D3B >=3D3B __cdecl<BR>&=
>gt=3D3B >=3D3B =3D
>> >RTProcess__RegisterForkHandlers(<BR>>=3D3B >=3D3B ForkHandler prepar=
>e=3D2C<BR=3D
>> >>>=3D3B >=3D3B ForkHandler parent=3D2C<BR>>=3D3B >=3D3B ForkHand=
>ler child)<BR=3D
>> >>>=3D3B >=3D3B {<BR>>=3D3B >=3D3B /* FreeBSD <=3D3B 6 lacks pt=
>hread_atfork.=3D
>> > Would be good to use autoconf.<BR>>=3D3B >=3D3B * VMS lacks pthread=
>_atfork=3D
>> >? Would be good to use autoconf.<BR>>=3D3B >=3D3B * Win32 lacks pthr=
>ead_atf=3D
>> >ork and fork. OK.<BR>>=3D3B >=3D3B *<BR>>=3D3B >=3D3B * As well=
>=3D2C for all =3D
>> >Posix systems=3D2C we could implement<BR>>=3D3B >=3D3B * atfork ours=
>elves=3D2C =3D
>> >as long as we provide a fork()<BR>>=3D3B >=3D3B * wrapper that code =
>uses.<B=3D
>> >R>>=3D3B >=3D3B */<BR>>=3D3B >=3D3B #if defined(_WIN32) \<BR>>=
>=3D3B >=3D3B =3D
>> >|| defined(__vms) \<BR>>=3D3B >=3D3B || (defined(__FreeBSD__) /* &am=
>p=3D3B&am=3D
>> >p=3D3B (__FreeBSD__ <=3D3B 6)*/ )<BR>>=3D3B >=3D3B return 0=3D3B<B=
>R>>=3D3B >=3D
>> >=3D3B #else<BR>>=3D3B >=3D3B while (1)<BR>>=3D3B >=3D3B {<BR>>=
>=3D3B >=3D3B in=3D
>> >t i =3D3D pthread_atfork(prepare=3D2C parent=3D2C child)=3D3B<BR>>=3D3=
>B >=3D3B if (=3D
>> >i !=3D3D EAGAIN)<BR>>=3D3B >=3D3B return i=3D3B<BR>>=3D3B >=3D3B=
> sleep(0)=3D3B<BR=3D
>> >>>=3D3B >=3D3B }<BR>>=3D3B >=3D3B #endif<BR>>=3D3B >=3D3B }<=
>BR>>=3D3B <BR> =3D
>> > </body>
>> ></html>=3D
>> >
>> >--_3dd397d4-ac1d-4148-a9ff-059d27dd794a_--
> =
>
>--_9d99325a-59cc-496a-9b87-3881dbf2b655_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Previously: user threads: all threads survived fork()<br>Previously: pthrea=
>ds: only the thread calling fork() survived fork()<br>Now: user threads and=
> pthreads: only the thread calling fork() survives fork()<br>This must be h=
>ow pthreads behave=2C and this makes user threads and pthreads consistent.<=
>br>
>This change depends on pthread_atfork=2C for pthreads and user threads.<br>=
>It only really matters to the rare "fork + do more work" program=2C such as=
> cvsupd.<br>Most programs either never fork=2C or exec almost immediately a=
>fter fork.<br><br><br>pthread_atfork offers a good model.<br>A sort of "dis=
>tributed" model.<br>You don't have to go and change all the calls to fork()=
>.<br>Each module with a need to do something before/after fork=2C calls the=
> central pthread_atfork=2C<br>and fork and pthread_atfork cooperate to do w=
>hat is needed.<br><br><br>No function pointer is needed.<br>Instead move th=
>e code to m3core/thread.<br><br><br>If you really must not use -pthread=2C =
>then you must implement pthread_atfork functionality<br>yourself and have a=
>ll fork() calls go through your own fork() wrapper that cooperates<br>with =
>your pthread_atfork replacement.<br>There is no free lunch -- there is a do=
>wnside to this approach=2C as plain fork() calls<br>are ok and correct if p=
>thread_atfork is used=2C but now become incorrect.<br>Pick your poison:<br>=
> =3B user thread/pthread inconsistency<br> =3B cvsupd incompatibili=
>ty with pthreads <br> =3B user threads using pthread_atfork/-pthread <b=
>r> =3B fork() calls having to go through a wrapper (ok -- you could mis=
>s this and <br> =3B =3B not likely notice -- only fork() calls in f=
>ork+do-more-work programs need the wrapper). <br><br><br>(Most of this has =
>been explained multiple times=2C but people only pay attention<br>when they=
> think it affects them. I'm guilty of the same thing.)<br><br><br> =3B-=
> Jay<br><br><br>>=3B To: jay.krell at cornell.edu<br>>=3B Date: Mon=2C 18 =
>Apr 2011 19:30:58 -0700<br>>=3B From: mika at async.caltech.edu<br>>=3B CC=
>: m3devel at elegosoft.com<br>>=3B Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 b=
>reakage=2C kernel 2.6.23=2C glibc-2.6-4<br>>=3B <br>>=3B <br>>=3B If =
>you or Tony could describe roughly what you think needs to be done<br>>=
>=3B I'd be happy to look into it.<br>>=3B <br>>=3B The basic problem is=
> that a decision that's made/described in<br>>=3B m3core/thread/m3makefil=
>e needs to someone find its way to controlling<br>>=3B what C code gets c=
>ompiled elsewhere in the system. Or maybe there should<br>>=3B be an ind=
>irection into the thread library to pick up pthread_atfork (or not).<br>>=
>=3B <br>>=3B But then again you still haven't explained why you made the =
>user threads use<br>>=3B pthread_atfork. I just remove it from my instal=
>lations=2C but then again I'm<br>>=3B not trying to run CVSup so I don't =
>know if it breaks that program to do so.<br>>=3B <br>>=3B Mika<br>=
>>=3B <br>>=3B Jay K writes:<br>>=3B >=3B--_3dd397d4-ac1d-4148-a9ff-=
>059d27dd794a_<br>>=3B >=3BContent-Type: text/plain=3B charset=3D"iso-88=
>59-1"<br>>=3B >=3BContent-Transfer-Encoding: quoted-printable<br>>=3B=
> >=3B<br>>=3B >=3B<br>>=3B >=3B>=3B The following code from RTP=
>rocessC.c ensures that it is neeeded on every =3D<br>>=3B >=3BUnix exce=
>pt<br>>=3B >=3B>=3B >=3B /* NOTE: Even userthreads now depends<br>&=
>gt=3B >=3B>=3B >=3B * on availability of pthreads.<br>>=3B >=3B&g=
>t=3B >=3B * This can be fixed if need be.<br>>=3B >=3B>=3B >=3B *=
>/<br>>=3B >=3B<br>>=3B >=3B=3D20<br>>=3B >=3BOk=3D2C "we" shoul=
>d probably go ahead and fix that.<br>>=3B >=3BI'll try to=3D2C but no p=
>romises=3D2C sorry.<br>>=3B >=3B=3D20<br>>=3B >=3B - Jay<br>>=3B =
>>=3B=3D20<br>>=3B >=3B>=3B From: hosking at cs.purdue.edu<br>>=3B &g=
>t=3B>=3B Date: Mon=3D2C 18 Apr 2011 18:11:26 -0400<br>>=3B >=3B>=3B=
> To: mika at async.caltech.edu<br>>=3B >=3B>=3B CC: m3devel at elegosoft.co=
>m<br>>=3B >=3B>=3B Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage=
>=3D2C kernel 2.6.23=3D2C glib=3D<br>>=3B >=3Bc-2.6-4<br>>=3B >=3B&g=
>t=3B=3D20<br>>=3B >=3B>=3B Probably unnecessary=3D2C given that I thi=
>nk there is another entry point t=3D<br>>=3B >=3Bo forking a process (I=
> forget where) in the thread-specific portion of m3co=3D<br>>=3B >=3Bre=
>. In which case the necessary work might be done there?<br>>=3B >=3B>=
>=3B=3D20<br>>=3B >=3B>=3B On Apr 18=3D2C 2011=3D2C at 2:45 PM=3D2C Mi=
>ka Nystrom wrote:<br>>=3B >=3B>=3B=3D20<br>>=3B >=3B>=3B >=3B=
> Tony Hosking writes:<br>>=3B >=3B>=3B >=3B ...<br>>=3B >=3B>=
>=3B >=3B>=3B pthread_atfork should not be needed under user threads.<br=
>>>=3B >=3B>=3B >=3B ...<br>>=3B >=3B>=3B >=3B=3D20<br>>=
>=3B >=3B>=3B >=3B The following code from RTProcessC.c ensures that i=
>t is neeeded on ever=3D<br>>=3B >=3By Unix except<br>>=3B >=3B>=
>=3B >=3B FreeBSD before 6. The comment is from the checked-in source file=
>.<br>>=3B >=3B>=3B >=3B=3D20<br>>=3B >=3B>=3B >=3B /* NOTE:=
> Even userthreads now depends<br>>=3B >=3B>=3B >=3B * on availabili=
>ty of pthreads.<br>>=3B >=3B>=3B >=3B * This can be fixed if need b=
>e.<br>>=3B >=3B>=3B >=3B */<br>>=3B >=3B>=3B >=3B=3D20<br>&=
>gt=3B >=3B>=3B >=3B INTEGER<br>>=3B >=3B>=3B >=3B __cdecl<br>=
>>=3B >=3B>=3B >=3B RTProcess__RegisterForkHandlers(<br>>=3B >=
>=3B>=3B >=3B ForkHandler prepare=3D2C<br>>=3B >=3B>=3B >=3B For=
>kHandler parent=3D2C<br>>=3B >=3B>=3B >=3B ForkHandler child)<br>&g=
>t=3B >=3B>=3B >=3B {<br>>=3B >=3B>=3B >=3B /* FreeBSD <=3B =
>6 lacks pthread_atfork. Would be good to use autoconf.<br>>=3B >=3B>=
>=3B >=3B * VMS lacks pthread_atfork? Would be good to use autoconf.<br>&g=
>t=3B >=3B>=3B >=3B * Win32 lacks pthread_atfork and fork. OK.<br>>=
>=3B >=3B>=3B >=3B *<br>>=3B >=3B>=3B >=3B * As well=3D2C for =
>all Posix systems=3D2C we could implement<br>>=3B >=3B>=3B >=3B * a=
>tfork ourselves=3D2C as long as we provide a fork()<br>>=3B >=3B>=3B =
>>=3B * wrapper that code uses.<br>>=3B >=3B>=3B >=3B */<br>>=3B=
> >=3B>=3B >=3B #if defined(_WIN32) \<br>>=3B >=3B>=3B >=3B ||=
> defined(__vms) \<br>>=3B >=3B>=3B >=3B || (defined(__FreeBSD__) /*=
> &=3B&=3B (__FreeBSD__ <=3B 6)*/ )<br>>=3B >=3B>=3B >=3B re=
>turn 0=3D3B<br>>=3B >=3B>=3B >=3B #else<br>>=3B >=3B>=3B >=
>=3B while (1)<br>>=3B >=3B>=3B >=3B {<br>>=3B >=3B>=3B >=3B=
> int i =3D3D pthread_atfork(prepare=3D2C parent=3D2C child)=3D3B<br>>=3B =
>>=3B>=3B >=3B if (i !=3D3D EAGAIN)<br>>=3B >=3B>=3B >=3B retu=
>rn i=3D3B<br>>=3B >=3B>=3B >=3B sleep(0)=3D3B<br>>=3B >=3B>=
>=3B >=3B }<br>>=3B >=3B>=3B >=3B #endif<br>>=3B >=3B>=3B &g=
>t=3B }<br>>=3B >=3B>=3B=3D20<br>>=3B >=3B =3D<br>>=
>=3B >=3B<br>>=3B >=3B--_3dd397d4-ac1d-4148-a9ff-059d27dd794a_<br>>=
>=3B >=3BContent-Type: text/html=3B charset=3D"iso-8859-1"<br>>=3B >=
>=3BContent-Transfer-Encoding: quoted-printable<br>>=3B >=3B<br>>=3B &=
>gt=3B<=3Bhtml>=3B<br>>=3B >=3B<=3Bhead>=3B<br>>=3B >=3B<=
>=3Bstyle>=3B<=3B!--<br>>=3B >=3B.hmmessage P<br>>=3B >=3B{<br>&=
>gt=3B >=3Bmargin:0px=3D3B<br>>=3B >=3Bpadding:0px<br>>=3B >=3B}<b=
>r>>=3B >=3Bbody.hmmessage<br>>=3B >=3B{<br>>=3B >=3Bfont-size: =
>10pt=3D3B<br>>=3B >=3Bfont-family:Tahoma<br>>=3B >=3B}<br>>=3B &g=
>t=3B-->=3B<=3B/style>=3B<br>>=3B >=3B<=3B/head>=3B<br>>=3B =
>>=3B<=3Bbody class=3D3D'hmmessage'>=3B<br>>=3B >=3B&=3Bgt=3D3B=
> The following code from RTProcessC.c ensures that it is neeeded on e=3D<br=
>>>=3B >=3Bvery Unix except<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B /=
>* NOTE: Even userthreads now depends<=3BBR>=3B=3D<br>>=3B >=3B&=
>=3Bgt=3D3B &=3Bgt=3D3B * on availability of pthreads.<=3BBR>=3B&=
>=3Bgt=3D3B &=3Bgt=3D3B * This can be=3D<br>>=3B >=3B fixed if need b=
>e.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B */<=3BBR>=3B<=3BBR>=
>=3B<br>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<br>>=3B >=3BOk=3D2C =
>"we" should probably go ahead and fix that.<=3BBR>=3B<br>>=3B >=3BI=
>'ll try to=3D2C but no&=3Bnbsp=3D3Bpromises=3D2C sorry.<=3BBR>=3B<br=
>>>=3B >=3B&=3Bnbsp=3D3B<=3BBR>=3B<br>>=3B >=3B&=3Bnbsp=3D=
>3B- Jay<=3BBR>=3B&=3Bnbsp=3D3B<=3BBR>=3B<br>>=3B >=3B&=3B=
>gt=3D3B From: hosking at cs.purdue.edu<=3BBR>=3B&=3Bgt=3D3B Date: Mon=
>=3D2C 18 Apr 2011 18:11=3D<br>>=3B >=3B:26 -0400<=3BBR>=3B&=3Bgt=
>=3D3B To: mika at async.caltech.edu<=3BBR>=3B&=3Bgt=3D3B CC: m3devel at el=
>egos=3D<br>>=3B >=3Boft.com<=3BBR>=3B&=3Bgt=3D3B Subject: Re: [M=
>3devel] 5.8.6 LINUXLIBC6 breakage=3D2C kerne=3D<br>>=3B >=3Bl 2.6.23=3D=
>2C glibc-2.6-4<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B Pro=
>bably unnecessary=3D2C given =3D<br>>=3B >=3Bthat I think there is anot=
>her entry point to forking a process (I forget wh=3D<br>>=3B >=3Bere) i=
>n the thread-specific portion of m3core. In which case the necessary =3D<br=
>>>=3B >=3Bwork might be done there?<=3BBR>=3B&=3Bgt=3D3B <=3BB=
>R>=3B&=3Bgt=3D3B On Apr 18=3D2C 2011=3D2C at 2:45=3D<br>>=3B >=3B =
>PM=3D2C Mika Nystrom wrote:<=3BBR>=3B&=3Bgt=3D3B <=3BBR>=3B&=
>=3Bgt=3D3B &=3Bgt=3D3B Tony Hosking writes:=3D<br>>=3B >=3B<=3BBR&=
>gt=3B&=3Bgt=3D3B &=3Bgt=3D3B ...<=3BBR>=3B&=3Bgt=3D3B &=3Bg=
>t=3D3B&=3Bgt=3D3B pthread_atfork should not be n=3D<br>>=3B >=3Beede=
>d under user threads.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B ...<=3BB=
>R>=3B&=3Bgt=3D3B &=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B =3D<br>&g=
>t=3B >=3B&=3Bgt=3D3B The following code from RTProcessC.c ensures that=
> it is neeeded on e=3D<br>>=3B >=3Bvery Unix except<=3BBR>=3B&=
>=3Bgt=3D3B &=3Bgt=3D3B FreeBSD before 6. The comment is from the=3D<br>&=
>gt=3B >=3B checked-in source file.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=
>=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B /* NOTE: Even u=3D<br>>=
>=3B >=3Bserthreads now depends<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B=
> * on availability of pthreads.<=3BBR>=3B&=3B=3D<br>>=3B >=3Bgt=
>=3D3B &=3Bgt=3D3B * This can be fixed if need be.<=3BBR>=3B&=3Bgt=
>=3D3B &=3Bgt=3D3B */<=3BBR>=3B&=3Bgt=3D3B =3D<br>>=3B >=3B&am=
>p=3Bgt=3D3B <=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B INTEGER<=3BBR>=
>=3B&=3Bgt=3D3B &=3Bgt=3D3B __cdecl<=3BBR>=3B&=3Bgt=3D3B &=
>=3Bgt=3D3B =3D<br>>=3B >=3BRTProcess__RegisterForkHandlers(<=3BBR>=
>=3B&=3Bgt=3D3B &=3Bgt=3D3B ForkHandler prepare=3D2C<=3BBR=3D<br>>=
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B ForkHandler parent=3D2C<=3B=
>BR>=3B&=3Bgt=3D3B &=3Bgt=3D3B ForkHandler child)<=3BBR=3D<br>>=
>=3B >=3B>=3B&=3Bgt=3D3B &=3Bgt=3D3B {<=3BBR>=3B&=3Bgt=3D3B=
> &=3Bgt=3D3B /* FreeBSD &=3Blt=3D3B 6 lacks pthread_atfork.=3D<br>>=
>=3B >=3B Would be good to use autoconf.<=3BBR>=3B&=3Bgt=3D3B &=
>=3Bgt=3D3B * VMS lacks pthread_atfork=3D<br>>=3B >=3B? Would be good to=
> use autoconf.<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B * Win32 lacks pth=
>read_atf=3D<br>>=3B >=3Bork and fork. OK.<=3BBR>=3B&=3Bgt=3D3B &=
>amp=3Bgt=3D3B *<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B * As well=3D2C f=
>or all =3D<br>>=3B >=3BPosix systems=3D2C we could implement<=3BBR>=
>=3B&=3Bgt=3D3B &=3Bgt=3D3B * atfork ourselves=3D2C =3D<br>>=3B >=
>=3Bas long as we provide a fork()<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3=
>B * wrapper that code uses.<=3BB=3D<br>>=3B >=3BR>=3B&=3Bgt=3D3B=
> &=3Bgt=3D3B */<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B #if defined(_=
>WIN32) \<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B =3D<br>>=3B >=3B|| =
>defined(__vms) \<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B || (defined(__F=
>reeBSD__) /* &=3Bamp=3D3B&=3Bam=3D<br>>=3B >=3Bp=3D3B (__FreeBSD_=
>_ &=3Blt=3D3B 6)*/ )<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B return 0=
>=3D3B<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D<br>>=3B >=3B=3D3B #else&=
>lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B while (1)<=3BBR>=3B&=3Bgt=
>=3D3B &=3Bgt=3D3B {<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B in=3D<br>=
>>=3B >=3Bt i =3D3D pthread_atfork(prepare=3D2C parent=3D2C child)=3D3B&=
>lt=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B if (=3D<br>>=3B >=3Bi !=3D3D=
> EAGAIN)<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B return i=3D3B<=3BBR&g=
>t=3B&=3Bgt=3D3B &=3Bgt=3D3B sleep(0)=3D3B<=3BBR=3D<br>>=3B >=3B=
>>=3B&=3Bgt=3D3B &=3Bgt=3D3B }<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=
>=3D3B #endif<=3BBR>=3B&=3Bgt=3D3B &=3Bgt=3D3B }<=3BBR>=3B&=
>=3Bgt=3D3B <=3BBR>=3B =3D<br>>=3B >=3B <=3B/body>=3B<=
>br>>=3B >=3B<=3B/html>=3B=3D<br>>=3B >=3B<br>>=3B >=3B--_3d=
>d397d4-ac1d-4148-a9ff-059d27dd794a_--<br> </body>
></html>=
>
>--_9d99325a-59cc-496a-9b87-3881dbf2b655_--
More information about the M3devel
mailing list