S
Steve D
I've created an application that opens sockets (using IO::Socket) and
then creates two ithreads, one that reads the socket and one that
writes it. It appears that if there is a "read" pending (sysread,
recv, or read) on a socket, then a "write" (syswrite, send or print)
on that socket hangs.
(In fact, it appears that if there is a "read" on *any* socket file
handle, then a "write" on any other hangs, but I need to verify that
carefully).
Before I put the reader's in, the writers were working just fine.
Is this known behavior with sockets?
How about with IO::Socket?
I'm trying to determine if there is a bug in my code, or if this is
known behavior.
Any good solutions?
Would IO::Select on the file-handle's in the reader's suffice to keep
the file-handle's clear for the writers to succeed?
Or will that fail too (if IO::Select somehow locks a file-handle).
Would Socket work better than IO::Socket without doing a select?
Regards,
Steve D
then creates two ithreads, one that reads the socket and one that
writes it. It appears that if there is a "read" pending (sysread,
recv, or read) on a socket, then a "write" (syswrite, send or print)
on that socket hangs.
(In fact, it appears that if there is a "read" on *any* socket file
handle, then a "write" on any other hangs, but I need to verify that
carefully).
Before I put the reader's in, the writers were working just fine.
Is this known behavior with sockets?
How about with IO::Socket?
I'm trying to determine if there is a bug in my code, or if this is
known behavior.
Any good solutions?
Would IO::Select on the file-handle's in the reader's suffice to keep
the file-handle's clear for the writers to succeed?
Or will that fail too (if IO::Select somehow locks a file-handle).
Would Socket work better than IO::Socket without doing a select?
Regards,
Steve D