Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Semantics of threads

Reply
Thread Tools

Semantics of threads

 
 
Bo Lindbergh
Guest
Posts: n/a
 
      07-24-2006
perldoc perlthrtut says:
> Thinking of mixing fork() and threads? Please lie down and wait until
> the feeling passes. Be aware that the semantics of fork() vary between
> platforms. For example, some UNIX systems copy all the current threads
> into the child process, while others only copy the thread that called
> fork(). You have been warned!


Does this mean that if more than one thread exists, the qx operator,
the system function, and the open function in pipe mode all have
undefined behaviour?


/Bo Lindbergh
 
Reply With Quote
 
 
 
 
Ben Morrow
Guest
Posts: n/a
 
      07-24-2006

Quoth Bo Lindbergh <(E-Mail Removed)>:
> perldoc perlthrtut says:
> > Thinking of mixing fork() and threads? Please lie down and wait until
> > the feeling passes. Be aware that the semantics of fork() vary between
> > platforms. For example, some UNIX systems copy all the current threads
> > into the child process, while others only copy the thread that called
> > fork(). You have been warned!

>
> Does this mean that if more than one thread exists, the qx operator,
> the system function, and the open function in pipe mode all have
> undefined behaviour?


No. A Unix system destroys all threads but the main one when exec(2) is
called; on Windows qx/system/open '|-' use the win32 spawn (or maybe
CreateProcess? It comes to the same thing) function anyway.

Ben

--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit.|(E-Mail Removed)
Musica vel ipsas arbores et horridas movet feras. |
 
Reply With Quote
 
 
 
 
xhoster@gmail.com
Guest
Posts: n/a
 
      07-24-2006
Bo Lindbergh <(E-Mail Removed)> wrote:
> perldoc perlthrtut says:
> > Thinking of mixing fork() and threads? Please lie down and wait until
> > the feeling passes. Be aware that the semantics of fork() vary between
> > platforms. For example, some UNIX systems copy all the current threads
> > into the child process, while others only copy the thread that called
> > fork(). You have been warned!

>
> Does this mean that if more than one thread exists, the qx operator,
> the system function, and the open function in pipe mode all have
> undefined behaviour?


Excluding bugs, no, the behaviour is not undefined. Those operations are
not implemented merely as naive forks. They are implemented in different
ways on different machines, and (attempt to) take care of such issues.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
Bo Lindbergh
Guest
Posts: n/a
 
      07-25-2006
In article <20060724143437.507$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)
wrote:
> Bo Lindbergh <(E-Mail Removed)> wrote:
> > perldoc perlthrtut says:
> > > Thinking of mixing fork() and threads? Please lie down and wait until
> > > the feeling passes. Be aware that the semantics of fork() vary between
> > > platforms. For example, some UNIX systems copy all the current threads
> > > into the child process, while others only copy the thread that called
> > > fork(). You have been warned!

> >
> > Does this mean that if more than one thread exists, the qx operator,
> > the system function, and the open function in pipe mode all have
> > undefined behaviour?

>
> Excluding bugs, no, the behaviour is not undefined. Those operations are
> not implemented merely as naive forks. They are implemented in different
> ways on different machines, and (attempt to) take care of such issues.


Really? I looked at the source and found no attempts to block other
threads from running between the fork and the exec.


/Bo Lindbergh
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      07-25-2006
Bo Lindbergh <(E-Mail Removed)> wrote:
> In article <20060724143437.507$(E-Mail Removed)>, (E-Mail Removed)
> wrote:
> > Bo Lindbergh <(E-Mail Removed)> wrote:
> > > perldoc perlthrtut says:
> > > > Thinking of mixing fork() and threads? Please lie down and wait
> > > > until the feeling passes. Be aware that the semantics of fork()
> > > > vary between platforms. For example, some UNIX systems copy all
> > > > the current threads into the child process, while others only copy
> > > > the thread that called fork(). You have been warned!
> > >
> > > Does this mean that if more than one thread exists, the qx operator,
> > > the system function, and the open function in pipe mode all have
> > > undefined behaviour?

> >
> > Excluding bugs, no, the behaviour is not undefined. Those operations
> > are not implemented merely as naive forks. They are implemented in
> > different ways on different machines, and (attempt to) take care of
> > such issues.

>
> Really? I looked at the source and found no attempts to block other
> threads from running between the fork and the exec.


It would really help to know what version of the source you looked at, and
the file(s) and line numbers. Anyway, I think there are some destruction
flags that need to be cleared/bypassed on a fork done within a thread to
avoid problems, which are inherently bypassed by doing an exec so in that
case perhaps no other special code is needed. The key (under unix) seems
to be to explicitly exit the forked child, and not let it run off the end
of the thread. But I wouldn't gaurantee that to always work (and I
generally just avoid threads anyway on unix, so my experience is limited).


perl-5.8.8]$ perl -le 'use threads; async{warn "In thread"; sleep 2; if
(fork) { print "a"} else {}}->join(); print "b"; sleep 5'

In thread at -e line 1.
Unbalanced scopes: 3 more ENTERs than LEAVEs
Unbalanced saves: 8 more saves than restores
Unbalanced context: 2 more PUSHes than POPs
Segmentation fault (core dumped)

Adding an exit to the empty "else {}" solves this problem. However,
removing the "sleep 2;" also solves the problem, for reasons I don't
understand.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
Bo Lindbergh
Guest
Posts: n/a
 
      07-25-2006
In article <20060725150335.583$(E-Mail Removed)>, (E-Mail Removed)
wrote:

> Bo Lindbergh <(E-Mail Removed)> wrote:
> > Really? I looked at the source and found no attempts to block other
> > threads from running between the fork and the exec.

>
> It would really help to know what version of the source you looked at, and
> the file(s) and line numbers


5.9.3, pp_sys.c, line 3950: start of pp_system.
line 3956: taint handling.
line 3966: output buffer flushing.
line 3975: fork attempts start here.
No sign of any thread-related stuff.


/Bo Lindbergh
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      07-25-2006
Bo Lindbergh <(E-Mail Removed)> wrote:
> In article <20060725150335.583$(E-Mail Removed)>, (E-Mail Removed)
> wrote:
>
> > Bo Lindbergh <(E-Mail Removed)> wrote:
> > > Really? I looked at the source and found no attempts to block other
> > > threads from running between the fork and the exec.

> >
> > It would really help to know what version of the source you looked at,
> > and the file(s) and line numbers

>
> 5.9.3, pp_sys.c, line 3950: start of pp_system.
> line 3956: taint handling.
> line 3966: output buffer flushing.
> line 3975: fork attempts start here.


But only if the #ifdef is satisfied.

> No sign of any thread-related stuff.


Actually there is, if you dig down into the guts of the
PerlProc_fork procedure (or the Perl_my_fork procedure, which is what
it seems to resolve to). For all I know, that stuff is just a no-op on
some systems, but it is present for when it is needed.

Anyway, if you compare pp_fork and pp_system, you will see that pp_system
does not simply call pp_fork, and looks quite different from it. Once you
resolve all the indirection, it may turn out that they do the same thing on
your OS, but if so that is only because that is what works best for your
system. Sometimes doing the right thing and doing the naive thing turn out
to be the same thing--the difference is in whether you know it is the right
thing in your case.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
Ben Morrow
Guest
Posts: n/a
 
      07-25-2006

Quoth Bo Lindbergh <(E-Mail Removed)>:
>
> Really? I looked at the source and found no attempts to block other
> threads from running between the fork and the exec.


I think you're suffering from the same misconception as I was: fork
doesn't duplicate all the threads in the process, only the calling
thread. You get a single new thread in the new process, which is why you
need pthread_atfork, to clear up any mess (mutexes) left by the threads
which no longer exist in this process.

Otherwise, yes, there would be a race condition between fork and exec,
where another thread could do something significant (IO, whatever) that
wouldn't be destroyed by the exec.

Ben

--
For far more marvellous is the truth than any artists of the past imagined!
Why do the poets of the present not speak of it? What men are poets who can
speak of Jupiter if he were like a man, but if he is an immense spinning
sphere of methane and ammonia must be silent?~Feynmann~(E-Mail Removed)
 
Reply With Quote
 
Bo Lindbergh
Guest
Posts: n/a
 
      07-26-2006
In article <(E-Mail Removed)>,
Ben Morrow <(E-Mail Removed)> wrote:

> Quoth Bo Lindbergh <(E-Mail Removed)>:
> >
> > Really? I looked at the source and found no attempts to block other
> > threads from running between the fork and the exec.

>
> I think you're suffering from the same misconception as I was: fork
> doesn't duplicate all the threads in the process, only the calling
> thread.


So you claim that it's a documentation error: the "some UNIX systems
copy all the current threads into the child process" part should be
removed from perlthrtut?


/Bo Lindbergh
 
Reply With Quote
 
Ben Morrow
Guest
Posts: n/a
 
      07-26-2006

Quoth Bo Lindbergh <(E-Mail Removed)>:
> In article <(E-Mail Removed)>,
> Ben Morrow <(E-Mail Removed)> wrote:
>
> > Quoth Bo Lindbergh <(E-Mail Removed)>:
> > >
> > > Really? I looked at the source and found no attempts to block other
> > > threads from running between the fork and the exec.

> >
> > I think you're suffering from the same misconception as I was: fork
> > doesn't duplicate all the threads in the process, only the calling
> > thread.

>
> So you claim that it's a documentation error: the "some UNIX systems
> copy all the current threads into the child process" part should be
> removed from perlthrtut?


Err.... dunno. I know that's the case with pthreads as specced, but I
also know a lot of (mostly older) Unices don't follow (or predate) the
standard. I would be inclined to trust p5p to be more likely to get this
stuff right than me; and you *are* supposed to be able to call system
from a threaded Perl program, so I'd be seriously surprised if there's a
major problem with it hasn't been spotted yet.

Ben

--
I touch the fire and it freezes me, [(E-Mail Removed)]
I look into it and it's black.
Why can't I feel? My skin should crack and peel---
I want the fire back... Buffy, 'Once More With Feeling'
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Java Threads - Get running threads Pedro Pinto Java 2 04-08-2008 11:44 PM
[new to threads] threads with UI and loop Une bévue Ruby 0 06-14-2006 10:22 AM
TB View, Threads, Threads with unread The Invisible Man Firefox 1 03-20-2006 02:09 AM
Standard Threads vs Weightless Threads yoda Python 2 08-01-2005 09:12 PM
threads without threads sindica@gmail.com C Programming 4 08-27-2004 09:25 PM



Advertisments