develooper Front page | perl.perl5.porters | Postings from January 2004

threads question

Thread Next
Alan Burlison
January 25, 2004 07:25
threads question
Message ID:
Why was it thought that exiting a scope was a good mechanism for releasing 
locks, rather than an explicit unlock?

Also, perlthrtut says this:

      Thinking of mixing fork() and threads?  Please lie down and
      wait until the feeling passes-- but in case you really want
      to know, the semantics is that fork() duplicates all the
      threads.  (In UNIX, at least, other platforms will do
      something different.)

That isn't true on Solaris if you are linked against libpthread (perl is), 
and isn't true at all in the next release of Solaris - fork() has been 
changed to have fork1() semantics:

      In Solaris 10, a call to fork() is identical to  a  call  to
      fork1();  only the calling thread is replicated in the child
      process. This is the POSIX-specified behavior for fork().

      In previous releases of  Solaris,  the  behavior  of  fork()
      depended  on  whether or not the application was linked with
      the  POSIX  threads  library.  When  linked  with   -lthread
      (Solaris  Threads)  but  not  linked  with  -lpthread (POSIX
      Threads), fork() was the same  as  forkall().   When  linked
      with  -lpthread,  whether  or not also linked with -lthread,
      fork() was the same as fork1().

      In Solaris 10, neither -lthread nor  -lpthread  is  required
      for  multithreaded applications. The standard C library pro-
      vides all threading support for  both  sets  of  application
      programming    interfaces.     Applications   that   require
      replicate-all fork semantics must call forkall().

POSIX-compliant implementations should not use forkall() semantics, so the 
statement in perlthrtut is incorrect.

Alan Burlison

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