[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Tue Apr 19 18:08:43 CEST 2011


Hi all:
I think the worst case scenario is to adapt changes to modification of such bugs, or UNSAFE parts, if it just gets to pick of a portion of the system well stabilized then all we can that depended on that, I hope this stabilizes soon, then we can all share the rest of the things.

Thanks in advance


--- El mar, 19/4/11, Mika Nystrom <mika at async.caltech.edu> escribió:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: m3devel at elegosoft.com
> Fecha: martes, 19 de abril, 2011 10:29
> 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'>
> >> >&gt=3D3B The following code from
> RTProcessC.c ensures that it is neeeded=
> > on e=3D
> >> >very Unix except<BR>&gt=3D3B
> &gt=3D3B /* NOTE: Even userthreads now depe=
> >nds<BR>=3D
> >> >&gt=3D3B &gt=3D3B * on availability of
> pthreads.<BR>&gt=3D3B &gt=3D3B * =
> >This can be=3D
> >> > fixed if need be.<BR>&gt=3D3B
> &gt=3D3B */<BR><BR>
> >> >&nbsp=3D3B<BR>
> >> >Ok=3D2C "we" should probably go ahead and fix
> that.<BR>
> >> >I'll try to=3D2C but
> no&nbsp=3D3Bpromises=3D2C sorry.<BR>
> >> >&nbsp=3D3B<BR>
> >> >&nbsp=3D3B-
> Jay<BR>&nbsp=3D3B<BR>
> >> >&gt=3D3B From: hosking at cs.purdue.edu<BR>&gt=3D3B
> Date: Mon=3D2C 18 Apr 2=
> >011 18:11=3D
> >> >:26 -0400<BR>&gt=3D3B To: mika at async.caltech.edu<BR>&gt=3D3B
> CC: m3devel=
> >@elegos=3D
> >> >oft.com<BR>&gt=3D3B Subject: Re:
> [M3devel] 5.8.6 LINUXLIBC6 breakage=3D2=
> >C kerne=3D
> >> >l 2.6.23=3D2C
> glibc-2.6-4<BR>&gt=3D3B <BR>&gt=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>&gt=3D3B <BR>&gt=3D3B On Apr
> 18=3D2C 2011=
> >=3D2C at 2:45=3D
> >> > PM=3D2C Mika Nystrom
> wrote:<BR>&gt=3D3B <BR>&gt=3D3B
> &gt=3D3B Tony Hosk=
> >ing writes:=3D
> >> ><BR>&gt=3D3B &gt=3D3B
> ...<BR>&gt=3D3B &gt=3D3B&gt=3D3B
> pthread_atfork sh=
> >ould not be n=3D
> >> >eeded under user
> threads.<BR>&gt=3D3B &gt=3D3B
> ...<BR>&gt=3D3B &gt=3D3B =
> ><BR>&gt=3D3B =3D
> >> >&gt=3D3B The following code from
> RTProcessC.c ensures that it is neeeded=
> > on e=3D
> >> >very Unix except<BR>&gt=3D3B
> &gt=3D3B FreeBSD before 6. The comment is f=
> >rom the=3D
> >> > checked-in source file.<BR>&gt=3D3B
> &gt=3D3B <BR>&gt=3D3B &gt=3D3B /* N=
> >OTE: Even u=3D
> >> >serthreads now depends<BR>&gt=3D3B
> &gt=3D3B * on availability of pthread=
> >s.<BR>&=3D
> >> >gt=3D3B &gt=3D3B * This can be fixed if
> need be.<BR>&gt=3D3B &gt=3D3B */=
> ><BR>&gt=3D3B =3D
> >> >&gt=3D3B <BR>&gt=3D3B
> &gt=3D3B INTEGER<BR>&gt=3D3B &gt=3D3B
> __cdecl<BR>&=
> >gt=3D3B &gt=3D3B =3D
> >>
> >RTProcess__RegisterForkHandlers(<BR>&gt=3D3B
> &gt=3D3B ForkHandler prepar=
> >e=3D2C<BR=3D
> >> >>&gt=3D3B &gt=3D3B ForkHandler
> parent=3D2C<BR>&gt=3D3B &gt=3D3B ForkHand=
> >ler child)<BR=3D
> >> >>&gt=3D3B &gt=3D3B
> {<BR>&gt=3D3B &gt=3D3B /* FreeBSD &lt=3D3B
> 6 lacks pt=
> >hread_atfork.=3D
> >> > Would be good to use
> autoconf.<BR>&gt=3D3B &gt=3D3B * VMS lacks
> pthread=
> >_atfork=3D
> >> >? Would be good to use
> autoconf.<BR>&gt=3D3B &gt=3D3B * Win32 lacks
> pthr=
> >ead_atf=3D
> >> >ork and fork. OK.<BR>&gt=3D3B
> &gt=3D3B *<BR>&gt=3D3B &gt=3D3B * As
> well=
> >=3D2C for all =3D
> >> >Posix systems=3D2C we could
> implement<BR>&gt=3D3B &gt=3D3B * atfork ours=
> >elves=3D2C =3D
> >> >as long as we provide a
> fork()<BR>&gt=3D3B &gt=3D3B * wrapper that
> code =
> >uses.<B=3D
> >> >R>&gt=3D3B &gt=3D3B
> */<BR>&gt=3D3B &gt=3D3B #if defined(_WIN32)
> \<BR>&gt=
> >=3D3B &gt=3D3B =3D
> >> >|| defined(__vms) \<BR>&gt=3D3B
> &gt=3D3B || (defined(__FreeBSD__) /* &am=
> >p=3D3B&am=3D
> >> >p=3D3B (__FreeBSD__ &lt=3D3B 6)*/
> )<BR>&gt=3D3B &gt=3D3B return 0=3D3B<B=
> >R>&gt=3D3B &gt=3D
> >> >=3D3B #else<BR>&gt=3D3B &gt=3D3B
> while (1)<BR>&gt=3D3B &gt=3D3B
> {<BR>&gt=
> >=3D3B &gt=3D3B in=3D
> >> >t i =3D3D pthread_atfork(prepare=3D2C
> parent=3D2C child)=3D3B<BR>&gt=3D3=
> >B &gt=3D3B if (=3D
> >> >i !=3D3D EAGAIN)<BR>&gt=3D3B
> &gt=3D3B return i=3D3B<BR>&gt=3D3B
> &gt=3D3B=
> > sleep(0)=3D3B<BR=3D
> >> >>&gt=3D3B &gt=3D3B
> }<BR>&gt=3D3B &gt=3D3B
> #endif<BR>&gt=3D3B &gt=3D3B }<=
> >BR>&gt=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>=
> >&nbsp=3B user thread/pthread
> inconsistency<br>&nbsp=3B cvsupd incompatibili=
> >ty with pthreads <br>&nbsp=3B user threads
> using pthread_atfork/-pthread <b=
> >r>&nbsp=3B fork() calls having to go through a
> wrapper (ok -- you could mis=
> >s this and <br>&nbsp=3B&nbsp=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>&nbsp=3B-=
> > Jay<br><br><br>&gt=3B To: jay.krell at cornell.edu<br>&gt=3B
> Date: Mon=2C 18 =
> >Apr 2011 19:30:58 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B
> CC=
> >: m3devel at elegosoft.com<br>&gt=3B
> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 b=
> >reakage=2C kernel 2.6.23=2C
> glibc-2.6-4<br>&gt=3B <br>&gt=3B
> <br>&gt=3B If =
> >you or Tony could describe roughly what you think needs
> to be done<br>&gt=
> >=3B I'd be happy to look into it.<br>&gt=3B
> <br>&gt=3B The basic problem is=
> > that a decision that's made/described
> in<br>&gt=3B m3core/thread/m3makefil=
> >e needs to someone find its way to
> controlling<br>&gt=3B what C code gets c=
> >ompiled elsewhere in the system.  Or maybe there
> should<br>&gt=3B be an ind=
> >irection into the thread library to pick up
> pthread_atfork (or not).<br>&gt=
> >=3B <br>&gt=3B But then again you still
> haven't explained why you made the =
> >user threads use<br>&gt=3B
> pthread_atfork.  I just remove it from my instal=
> >lations=2C but then again I'm<br>&gt=3B not
> trying to run CVSup so I don't =
> >know if it breaks that program to do
> so.<br>&gt=3B <br>&gt=3B   
>   Mika<br>=
> >&gt=3B <br>&gt=3B Jay K
> writes:<br>&gt=3B
> &gt=3B--_3dd397d4-ac1d-4148-a9ff-=
> >059d27dd794a_<br>&gt=3B
> &gt=3BContent-Type: text/plain=3B charset=3D"iso-88=
> >59-1"<br>&gt=3B
> &gt=3BContent-Transfer-Encoding:
> quoted-printable<br>&gt=3B=
> > &gt=3B<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3B&gt=3B The
> following code from RTP=
> >rocessC.c ensures that it is neeeded on every
> =3D<br>&gt=3B &gt=3BUnix exce=
> >pt<br>&gt=3B &gt=3B&gt=3B &gt=3B
> /* NOTE: Even userthreads now depends<br>&=
> >gt=3B &gt=3B&gt=3B &gt=3B * on availability
> of pthreads.<br>&gt=3B &gt=3B&g=
> >t=3B &gt=3B * This can be fixed if need
> be.<br>&gt=3B &gt=3B&gt=3B &gt=3B *=
> >/<br>&gt=3B &gt=3B<br>&gt=3B
> &gt=3B=3D20<br>&gt=3B &gt=3BOk=3D2C "we"
> shoul=
> >d probably go ahead and fix that.<br>&gt=3B
> &gt=3BI'll try to=3D2C but no p=
> >romises=3D2C sorry.<br>&gt=3B
> &gt=3B=3D20<br>&gt=3B &gt=3B -
> Jay<br>&gt=3B =
> >&gt=3B=3D20<br>&gt=3B
> &gt=3B&gt=3B From: hosking at cs.purdue.edu<br>&gt=3B
> &g=
> >t=3B&gt=3B Date: Mon=3D2C 18 Apr 2011 18:11:26
> -0400<br>&gt=3B &gt=3B&gt=3B=
> > To: mika at async.caltech.edu<br>&gt=3B
> &gt=3B&gt=3B CC: m3devel at elegosoft.co=
> >m<br>&gt=3B &gt=3B&gt=3B Subject: Re:
> [M3devel] 5.8.6 LINUXLIBC6 breakage=
> >=3D2C kernel 2.6.23=3D2C glib=3D<br>&gt=3B
> &gt=3Bc-2.6-4<br>&gt=3B &gt=3B&g=
> >t=3B=3D20<br>&gt=3B &gt=3B&gt=3B
> Probably unnecessary=3D2C given that I thi=
> >nk there is another entry point
> t=3D<br>&gt=3B &gt=3Bo forking a process (I=
> > forget where) in the thread-specific portion of
> m3co=3D<br>&gt=3B &gt=3Bre=
> >. In which case the necessary work might be done
> there?<br>&gt=3B &gt=3B&gt=
> >=3B=3D20<br>&gt=3B &gt=3B&gt=3B On
> Apr 18=3D2C 2011=3D2C at 2:45 PM=3D2C Mi=
> >ka Nystrom wrote:<br>&gt=3B
> &gt=3B&gt=3B=3D20<br>&gt=3B
> &gt=3B&gt=3B &gt=3B=
> > Tony Hosking writes:<br>&gt=3B
> &gt=3B&gt=3B &gt=3B ...<br>&gt=3B
> &gt=3B&gt=
> >=3B &gt=3B&gt=3B pthread_atfork should not be
> needed under user threads.<br=
> >>&gt=3B &gt=3B&gt=3B &gt=3B
> ...<br>&gt=3B &gt=3B&gt=3B
> &gt=3B=3D20<br>&gt=
> >=3B &gt=3B&gt=3B &gt=3B The following code
> from RTProcessC.c ensures that i=
> >t is neeeded on ever=3D<br>&gt=3B &gt=3By
> Unix except<br>&gt=3B &gt=3B&gt=
> >=3B &gt=3B FreeBSD before 6. The comment is from
> the checked-in source file=
> >.<br>&gt=3B &gt=3B&gt=3B
> &gt=3B=3D20<br>&gt=3B &gt=3B&gt=3B
> &gt=3B /* NOTE:=
> > Even userthreads now depends<br>&gt=3B
> &gt=3B&gt=3B &gt=3B * on availabili=
> >ty of pthreads.<br>&gt=3B
> &gt=3B&gt=3B &gt=3B * This can be fixed if need
> b=
> >e.<br>&gt=3B &gt=3B&gt=3B &gt=3B
> */<br>&gt=3B &gt=3B&gt=3B
> &gt=3B=3D20<br>&=
> >gt=3B &gt=3B&gt=3B &gt=3B
> INTEGER<br>&gt=3B &gt=3B&gt=3B &gt=3B
> __cdecl<br>=
> >&gt=3B &gt=3B&gt=3B &gt=3B
> RTProcess__RegisterForkHandlers(<br>&gt=3B
> &gt=
> >=3B&gt=3B &gt=3B ForkHandler
> prepare=3D2C<br>&gt=3B &gt=3B&gt=3B
> &gt=3B For=
> >kHandler parent=3D2C<br>&gt=3B
> &gt=3B&gt=3B &gt=3B ForkHandler
> child)<br>&g=
> >t=3B &gt=3B&gt=3B &gt=3B
> {<br>&gt=3B &gt=3B&gt=3B &gt=3B /*
> FreeBSD &lt=3B =
> >6 lacks pthread_atfork. Would be good to use
> autoconf.<br>&gt=3B &gt=3B&gt=
> >=3B &gt=3B * VMS lacks pthread_atfork? Would be
> good to use autoconf.<br>&g=
> >t=3B &gt=3B&gt=3B &gt=3B * Win32 lacks
> pthread_atfork and fork. OK.<br>&gt=
> >=3B &gt=3B&gt=3B &gt=3B
> *<br>&gt=3B &gt=3B&gt=3B &gt=3B * As
> well=3D2C for =
> >all Posix systems=3D2C we could
> implement<br>&gt=3B &gt=3B&gt=3B
> &gt=3B * a=
> >tfork ourselves=3D2C as long as we provide a
> fork()<br>&gt=3B &gt=3B&gt=3B =
> >&gt=3B * wrapper that code
> uses.<br>&gt=3B &gt=3B&gt=3B &gt=3B
> */<br>&gt=3B=
> > &gt=3B&gt=3B &gt=3B #if defined(_WIN32)
> \<br>&gt=3B &gt=3B&gt=3B &gt=3B ||=
> > defined(__vms) \<br>&gt=3B
> &gt=3B&gt=3B &gt=3B || (defined(__FreeBSD__)
> /*=
> > &amp=3B&amp=3B (__FreeBSD__ &lt=3B 6)*/
> )<br>&gt=3B &gt=3B&gt=3B &gt=3B re=
> >turn 0=3D3B<br>&gt=3B &gt=3B&gt=3B
> &gt=3B #else<br>&gt=3B &gt=3B&gt=3B
> &gt=
> >=3B while (1)<br>&gt=3B &gt=3B&gt=3B
> &gt=3B {<br>&gt=3B &gt=3B&gt=3B
> &gt=3B=
> > int i =3D3D pthread_atfork(prepare=3D2C parent=3D2C
> child)=3D3B<br>&gt=3B =
> >&gt=3B&gt=3B &gt=3B if (i !=3D3D
> EAGAIN)<br>&gt=3B &gt=3B&gt=3B &gt=3B
> retu=
> >rn i=3D3B<br>&gt=3B &gt=3B&gt=3B
> &gt=3B sleep(0)=3D3B<br>&gt=3B
> &gt=3B&gt=
> >=3B &gt=3B }<br>&gt=3B
> &gt=3B&gt=3B &gt=3B #endif<br>&gt=3B
> &gt=3B&gt=3B &g=
> >t=3B }<br>&gt=3B
> &gt=3B&gt=3B=3D20<br>&gt=3B &gt=3B
>    
>         
>           
>   =3D<br>&gt=
> >=3B &gt=3B<br>&gt=3B
> &gt=3B--_3dd397d4-ac1d-4148-a9ff-059d27dd794a_<br>&gt=
> >=3B &gt=3BContent-Type: text/html=3B
> charset=3D"iso-8859-1"<br>&gt=3B &gt=
> >=3BContent-Transfer-Encoding:
> quoted-printable<br>&gt=3B
> &gt=3B<br>&gt=3B &=
> >gt=3B&lt=3Bhtml&gt=3B<br>&gt=3B
> &gt=3B&lt=3Bhead&gt=3B<br>&gt=3B
> &gt=3B&lt=
> >=3Bstyle&gt=3B&lt=3B!--<br>&gt=3B
> &gt=3B.hmmessage P<br>&gt=3B
> &gt=3B{<br>&=
> >gt=3B &gt=3Bmargin:0px=3D3B<br>&gt=3B
> &gt=3Bpadding:0px<br>&gt=3B &gt=3B}<b=
> >r>&gt=3B
> &gt=3Bbody.hmmessage<br>&gt=3B
> &gt=3B{<br>&gt=3B &gt=3Bfont-size: =
> >10pt=3D3B<br>&gt=3B
> &gt=3Bfont-family:Tahoma<br>&gt=3B
> &gt=3B}<br>&gt=3B &g=
> >t=3B--&gt=3B&lt=3B/style&gt=3B<br>&gt=3B
> &gt=3B&lt=3B/head&gt=3B<br>&gt=3B =
> >&gt=3B&lt=3Bbody
> class=3D3D'hmmessage'&gt=3B<br>&gt=3B
> &gt=3B&amp=3Bgt=3D3B=
> > The following code from RTProcessC.c ensures that it
> is neeeded on e=3D<br=
> >>&gt=3B &gt=3Bvery Unix
> except&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B /=
> >* NOTE: Even userthreads now
> depends&lt=3BBR&gt=3B=3D<br>&gt=3B
> &gt=3B&amp=
> >=3Bgt=3D3B &amp=3Bgt=3D3B * on availability of
> pthreads.&lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B &amp=3Bgt=3D3B * This can
> be=3D<br>&gt=3B &gt=3B fixed if need b=
> >e.&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B
> */&lt=3BBR&gt=3B&lt=3BBR&gt=
> >=3B<br>&gt=3B
> &gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B<br>&gt=3B
> &gt=3BOk=3D2C =
> >"we" should probably go ahead and fix
> that.&lt=3BBR&gt=3B<br>&gt=3B
> &gt=3BI=
> >'ll try to=3D2C but no&amp=3Bnbsp=3D3Bpromises=3D2C
> sorry.&lt=3BBR&gt=3B<br=
> >>&gt=3B
> &gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B<br>&gt=3B
> &gt=3B&amp=3Bnbsp=3D=
> >3B-
> Jay&lt=3BBR&gt=3B&amp=3Bnbsp=3D3B&lt=3BBR&gt=3B<br>&gt=3B
> &gt=3B&amp=3B=
> >gt=3D3B From: hosking at cs.purdue.edu&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> Date: Mon=
> >=3D2C 18 Apr 2011 18:11=3D<br>&gt=3B
> &gt=3B:26 -0400&lt=3BBR&gt=3B&amp=3Bgt=
> >=3D3B To: mika at async.caltech.edu&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> CC: m3devel at el=
> >egos=3D<br>&gt=3B
> &gt=3Boft.com&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> Subject: Re: [M=
> >3devel] 5.8.6 LINUXLIBC6 breakage=3D2C
> kerne=3D<br>&gt=3B &gt=3Bl 2.6.23=3D=
> >2C glibc-2.6-4&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &lt=3BBR&gt=3B&amp=3Bgt=3D3B Pro=
> >bably unnecessary=3D2C given =3D<br>&gt=3B
> &gt=3Bthat I think there is anot=
> >her entry point to forking a process (I forget
> wh=3D<br>&gt=3B &gt=3Bere) i=
> >n the thread-specific portion of m3core. In which case
> the necessary =3D<br=
> >>&gt=3B &gt=3Bwork might be done
> there?&lt=3BBR&gt=3B&amp=3Bgt=3D3B &lt=3BB=
> >R&gt=3B&amp=3Bgt=3D3B On Apr 18=3D2C 2011=3D2C
> at 2:45=3D<br>&gt=3B &gt=3B =
> >PM=3D2C Mika Nystrom
> wrote:&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B &amp=3Bgt=3D3B Tony Hosking
> writes:=3D<br>&gt=3B &gt=3B&lt=3BBR&=
> >gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> ...&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bg=
> >t=3D3B&amp=3Bgt=3D3B pthread_atfork should not be
> n=3D<br>&gt=3B &gt=3Beede=
> >d under user
> threads.&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B ...&lt=3BB=
> >R&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> &lt=3BBR&gt=3B&amp=3Bgt=3D3B
> =3D<br>&g=
> >t=3B &gt=3B&amp=3Bgt=3D3B The following code
> from RTProcessC.c ensures that=
> > it is neeeded on e=3D<br>&gt=3B
> &gt=3Bvery Unix except&lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B &amp=3Bgt=3D3B FreeBSD before 6. The
> comment is from the=3D<br>&=
> >gt=3B &gt=3B checked-in source
> file.&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=
> >=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B /* NOTE: Even u=3D<br>&gt=
> >=3B &gt=3Bserthreads now
> depends&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B=
> > * on availability of
> pthreads.&lt=3BBR&gt=3B&amp=3B=3D<br>&gt=3B
> &gt=3Bgt=
> >=3D3B &amp=3Bgt=3D3B * This can be fixed if need
> be.&lt=3BBR&gt=3B&amp=3Bgt=
> >=3D3B &amp=3Bgt=3D3B
> */&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> =3D<br>&gt=3B &gt=3B&am=
> >p=3Bgt=3D3B &lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B INTEGER&lt=3BBR&gt=
> >=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> __cdecl&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
> >=3Bgt=3D3B =3D<br>&gt=3B
> &gt=3BRTProcess__RegisterForkHandlers(&lt=3BBR&gt=
> >=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B ForkHandler
> prepare=3D2C&lt=3BBR=3D<br>&gt=
> >=3B &gt=3B&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B ForkHandler parent=3D2C&lt=3B=
> >BR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> ForkHandler child)&lt=3BBR=3D<br>&gt=
> >=3B &gt=3B&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B
> {&lt=3BBR&gt=3B&amp=3Bgt=3D3B=
> > &amp=3Bgt=3D3B /* FreeBSD &amp=3Blt=3D3B 6
> lacks pthread_atfork.=3D<br>&gt=
> >=3B &gt=3B Would be good to use
> autoconf.&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=
> >=3Bgt=3D3B * VMS lacks
> pthread_atfork=3D<br>&gt=3B &gt=3B? Would be
> good to=
> > use autoconf.&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B * Win32 lacks pth=
> >read_atf=3D<br>&gt=3B &gt=3Bork and fork.
> OK.&lt=3BBR&gt=3B&amp=3Bgt=3D3B &=
> >amp=3Bgt=3D3B *&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B * As well=3D2C f=
> >or all =3D<br>&gt=3B &gt=3BPosix
> systems=3D2C we could implement&lt=3BBR&gt=
> >=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B * atfork
> ourselves=3D2C =3D<br>&gt=3B &gt=
> >=3Bas long as we provide a
> fork()&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3=
> >B * wrapper that code
> uses.&lt=3BB=3D<br>&gt=3B
> &gt=3BR&gt=3B&amp=3Bgt=3D3B=
> > &amp=3Bgt=3D3B
> */&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B #if defined(_=
> >WIN32) \&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B =3D<br>&gt=3B &gt=3B|| =
> >defined(__vms)
> \&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> || (defined(__F=
> >reeBSD__) /*
> &amp=3Bamp=3D3B&amp=3Bam=3D<br>&gt=3B
> &gt=3Bp=3D3B (__FreeBSD_=
> >_ &amp=3Blt=3D3B 6)*/
> )&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> return 0=
> >=3D3B&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D<br>&gt=3B &gt=3B=3D3B
> #else&=
> >lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> while (1)&lt=3BBR&gt=3B&amp=3Bgt=
> >=3D3B &amp=3Bgt=3D3B
> {&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> in=3D<br>=
> >&gt=3B &gt=3Bt i =3D3D
> pthread_atfork(prepare=3D2C parent=3D2C child)=3D3B&=
> >lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> if (=3D<br>&gt=3B &gt=3Bi !=3D3D=
> > EAGAIN)&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B return i=3D3B&lt=3BBR&g=
> >t=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> sleep(0)=3D3B&lt=3BBR=3D<br>&gt=3B
> &gt=3B=
> >&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=3D3B
> }&lt=3BBR&gt=3B&amp=3Bgt=3D3B &amp=3Bgt=
> >=3D3B #endif&lt=3BBR&gt=3B&amp=3Bgt=3D3B
> &amp=3Bgt=3D3B }&lt=3BBR&gt=3B&amp=
> >=3Bgt=3D3B &lt=3BBR&gt=3B
> =3D<br>&gt=3B &gt=3B   
>         
>           
>   &lt=3B/body&gt=3B<=
> >br>&gt=3B
> &gt=3B&lt=3B/html&gt=3B=3D<br>&gt=3B
> &gt=3B<br>&gt=3B &gt=3B--_3d=
> >d397d4-ac1d-4148-a9ff-059d27dd794a_--<br>
>    
>         
>           
>   </body>
> ></html>=
> >
> >--_9d99325a-59cc-496a-9b87-3881dbf2b655_--
> 



More information about the M3devel mailing list