Re: Timeout Handling (Re: WWW::HTTP )
Jack Shirazi - BIU (js@biu.icnet.uk)
Thu, 18 May 95 11:37:43 BST
> I could use select, and read the chunks in by hand and load them into
> lines, but that seems rather a lot of ugly work for Perl's
> reputation :-).
Why? This is something I'm seeing in alot of modules now. Using <>
because that is what people see. But these are meant as nice
comfortable shorthands in perl, if you are scripting and want to do it
quickly. But surely in a library we should use the most efficient
way available - spending the extra time to get it right.
Network sockets should be read and written using sysread and syswrite,
even if the protocol is line oriented. I've seen two problems crop
up now to do with fread buffering in the libwww context, one report
from Tim about lost stuff in the buffer, and one from Darrell Berry
who's doing the Mac port, about the same. select is actually a very
nice, elegant way to do things, and it would allow for the libwww
to be used in multiplexing code much more easily (again Darrell Berry
needs to do just that).
> So, are there any better solutions? Tim, have you got any more info of
> dying in a signal handler being unsafe?
I don't remember this coming up. There is nothing wrong with die'ing in
a handler. The only problems I know of are where you are in the signal
handler and another signal is received which affects the code in the
signal handler (such as calling another signal handler which updates
a global that the first signal handler is using). If the signal
handler is a simple die statement, then I don't see any problems with it
even if it were a process with a lot of signals flying about (which is
extremely unlikely for a libwww process).
A while ago I did an alarm call module which allowed nested timeouts -
it needs updating, but it might be useful here.