[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
Jay K
jay.krell at cornell.edu
Tue Apr 19 20:50:16 CEST 2011
It's easy enough for us to support either name.
- Jay
> To: jay.krell at cornell.edu
> Date: Tue, 19 Apr 2011 08:29:24 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
>
> 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_--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110419/e7432675/attachment-0002.html>
More information about the M3devel
mailing list