develooper Front page | perl.perl5.porters | Postings from July 2001

RE: [@11222] cannot compile -Duseithreads on freebsd-current

Thread Previous | Thread Next
From:
Richard Soderberg
Date:
July 9, 2001 01:54
Subject:
RE: [@11222] cannot compile -Duseithreads on freebsd-current
Message ID:
NAEKLNAAHLMBPMPNBMLEGEGNDIAA.rs@crystalflame.net
> On Sun, 08 Jul 2001 16:07:35 PDT, Richard Soderberg wrote:
> >I'm on freebsd-current having problems compiling @11222.
> >
> >Apparently pthread_atfork is in a shared library I can't
> seem to use -
> >/usr/compat/linux/lib/libpthread-0.8.so.
> >
> >And my tuits don't extend to understanding win32thread.h and
> >pthread_atfork today.
>
> The only code that is relevant in win32thread.h is this single line:
>
>     #define PTHREAD_ATFORK(prepare,parent,child)    NOOP
>
> which can be enabled in your hints as a cheap cop out (see below).

Indeed.

> >Can we emulate atfork or use the old dangerous code on platforms
> >without?
>
> You should be able to write a fork() wrapper that goes something like
> this:
>
>     Pid_t
>     my_fork(void)
>     {
>     #ifdef NO_PTHREAD_ATFORK /* ndef HAS_PTHREAD_ATFORK w/
> Configure smarts */
>         Pid_t ret;
>
> 	S_atfork_lock();
>         ret = fork();
> 	S_atfork_unlock();
> 	return ret;
>     #else
>         return fork();
>     #endif
>     }
>
> and then do this in iperlsys.h:
>
>     -#define PerlProc_fork()		fork()
>     +#define PerlProc_fork()		my_fork()
>
> and fix a couple of spots in util.c with the bare [v]fork() call with
> s/\bv?fork\b/PerlProc_fork/g.
>
> This however is only a 66% solution, because it only avoids
> the problem
> for perl's internal calls to fork(), and doesn't do anything about a
> library or extension that might call fork() or popen() at the C level.

Will consider this.

> I would suggest hunting down the real pthread_atfork() if at all
> possible.

My examination of the header files is finding nothing.  Seems to be a
linuxthreads specific function.

> >I guess we could also catch this in ./Configure and disable
> ithreads until
> >we find a workaround - but that feels icky.
>
> That sounds like going too far.  A quick "fix" that ignores
> the potential
> deadlock problem would be to just add -DPTHREAD_ATFORK(a,b,c)=NOOP to
> ccflags in your platform hints.

Fair enough.

> HTH,

Indeed it does.  It's unfortunate that this incredibly useful function
isn't in my pthreads library by default.

Of course, we can use the linux compat libs to get this, but I'm not
sure I want ithreads on freebsd to require linux compat to be installed.
That feels icky.

R.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About