[ale] Perl threads

[Christopher Fowler]

I found a solution that does not require threads.  The problem is that
the program keeps a list of remote hosts.  This list could be as long as
300 hosts.  At any time there could be 300 file descriptors in the
select() queue.  Every 5 minutes I walk the list in a round robin
fashion looking for dead hosts.  If a connect() can take as long as 60
seconds to timeout a list of only 10 hosts would consume 10 minutes of
time when the program should be read()inf and write()ing data.  

I took a hint from connect(3) man page:
EINPROGRESS
The  socket is non-blocking and the connection cannot be completed
immediately.  It is possible to select(2)
or poll(2) for completion by selecting the socket for writing. After
select indicates writability, use  get?
sockopt(2)  to  read the SO_ERROR option at level SOL_SOCKET to
determine whether connect completed success?
fully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual
error codes listed here, explaining
              the reason for the failure).

Now a list of 10 would attempt the connect in the background.  I add the
socket to the write selector then when it is okay to write I try to see
if getpeername succeeds.  If it does I then commence to log into the
remote device and when I'm done with that I remove it from the write
selector to the read selector.  Now the program can try to re connect to
dead hosts with causing huge delays.


On Wed, 2005-04-27 at 14:22, Fletch wrote:
> >>>>> "Christopher" == Christopher Fowler <cfowler at outpostsentinel.com> writes:
> 
>     Christopher> I looked at perthrtut and there seems to be a lock()
>     Christopher> function but no unlock.  I want to lock a variable in
>     Christopher> the main program as well as a thread.
> 
> If I remember correctly, locks are only active for the enclosing
> lexical scope (similar to the lifetime of a lexical variable declared
> with my).  The way to lock a smaller chunk of code is to wrap it in
> its own block with a lock($whoozits) at the top.  
> 
> 
> What you might want to do is use a higher level exclusion mechanism
> like Thread::Semaphore instead of the low level lock().
> 
> 
> Having said that, unless things have really changed conventional
> wisdom has been "don't use threads in Perl".  In general you'll be
> better served by forking coprocesses, or using POE and letting it hide
> the nastyness.