develooper Front page | perl.ithreads | Postings from February 2008

Passing an IO:Handle to a Thread

Thread Next
From:
Chris Hall
Date:
February 27, 2008 07:24
Subject:
Passing an IO:Handle to a Thread
Message ID:
yGAIL3OyBYxHFwIq@agrotera.halldom.com

With your indulgence, I seek enlightenment...

I have looked at the documentation and studied various modules,
including Thread::Queue, Thread::Queue::Any, Thread::Conveyor, ...  I
have read through the archive for this mailing list.

I am failing to grasp how stuff can be shared or passed between threads,
particularly Objects in general and IO::Handle objects in particular.

IO:: stuff doesn't say it's thread-safe -- but it doesn't say it isn't.
If threads and IO are incompatible that would be a serious deficiency
(Shirley?).

I can see that scalars, arrays and hashes can be shared, provided they
are either contain simple values or references to other shared scalars,
arrays and hashes.  I see examples of packaging up complex data to be
able to store it as a simple scalar.

1. how Objects fit into this in general.

   I note advice that the contents of an Object may be passed between
   threads, provided the receiving thread re-blesses the received data.

   I can see that Thread:Queue creates a shared array and then blesses
   it.  For several threads to use the queue one needs to pass the
   object.  If the queue object (reference) is stored in a shared
   scalar, will that work ?  Does each thread need to bless the thing ?

   Does an object shared in this way get DESTROYed once or once per
   thread ?

2. GLOBS in general and IO::Handle objects in particular.

   I find that I cannot do: my $FH :shared ;  open $FH, "...." ;

                       nor: my $FH ;  open $FH, "...." ;
                            my $sFH :shared = $FH ;

   I suppose I can pass $FH->fileno and use fdopen in the worker thread.

   If so, I've got two IO::Handle objects in separate threads, both
   capable of doing stuff...

   What happens when I close one of the IO::Handles ?  Or one is
   DESTROYed ?

3. Cannot assign sub addresses to a shared variable.

   If find that I cannot do: my $r_sub :shared = \&sub...

   which requires some other work around ?

4. More specifically -- IO::Socket objects.

   Assuming a listening socket in one thread, but each incoming
   connection should be handled in a separate thread...  The accept
   action:

      $connection_socket = $listen_socket->accept()

   requires that the connection thread can be passed either the
   $connection_socket or the $listen_socket.

   Assuming the fdopen trick works, what about all the properties held
   in the hash is the IO:Socket object ?

5. Arguments passed to new thread and return values from a thread.

   It would appear that these values are cloned.  Is that the case ?

6. Objects which are cloned either when a thread is created or passed as
   an argument.

   Cloned objects are apparently independent and hence will be DESTROYed
   separately.  This appears straightforward -- but what happens to
   shared objects ?

   Cloned IO::Handle or IO::Socket objects must somehow be linked to the
   same thing.  What happens when the first clone object is closed or
   DESTROYed.

It may be that 5.10.0 may be better than 5.8.8 at these things ?

Thanks,

Chris
-- 
Chris Hall               highwayman.com

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