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

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

Thread Previous | Thread Next
Gurusamy Sarathy
July 8, 2001 19:51
Re: [@11222] cannot compile -Duseithreads on freebsd-current
Message ID:
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 -
>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).

>Can we emulate atfork or use the old dangerous code on platforms

You should be able to write a fork() wrapper that goes something like

    #ifdef NO_PTHREAD_ATFORK /* ndef HAS_PTHREAD_ATFORK w/ Configure smarts */
        Pid_t ret;

        ret = fork();
	return ret;
        return fork();

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

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.

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

>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.



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About