[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Wed Apr 20 00:10:45 CEST 2011
Hi all:
since there was just that interface in *nix platforms, then it must be called like that , but another name will be just create SchedulerCM3, thus suggests SchedulerPosix would be called rather than nothing suffixing it SchedulerSRC and the other one Scheduler alone be the default like to say SchedulerCM3 AS Scheduler so to switch to SchedulerSRC AS Scheduler provided that both are implementation ready so one can select SchedulerCM3 as SchedulerSRC or Scheduler so one name comes after each rep rather than changing every other place each time, even of Internal Nodes as in m3tk which specifies its members as SRC_NODE <: AST_NODE then something like CM3_NODE likiwise subtyped if so should be created to hold the extensions (can somebody name them WIDECHAR, LONGINT, LONGCARD, what else am I missing if so?), like we could come up with something cleaner than just put all there.
I will try to se a proposal for that.
Thanks in advance
--- El mar, 19/4/11, Jay K <jay.krell at cornell.edu> escribió:
De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
Para: "Mika Nystrom" <mika at async.caltech.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: martes, 19 de abril, 2011 13:50
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/83389f24/attachment-0002.html>
More information about the M3devel
mailing list