On Dec 26, 2007 6:00 PM, Edi Weitz edi@agharta.de wrote:
On Wed, 26 Dec 2007 15:25:54 +0100, "Erik Huelsmann" ehuels@gmail.com wrote:
Well, I think they'll accept (a patch which fits into the usocket framework),
To the OP: In case that wasn't clear - Erik is the maintainer of usocket. So, if /he/ says so...
especially since timeouts come for free in Allegro and CLISP
And LispWorks.
Right, I meant "in addition to the LispWorks and SBCL timeouts which are implemented in the patch".
Actually, if I re-read the original posting and the reason for the time-outs, I think I have it already implemented in the usocket trunk (except for SBCL/Win32):
usocket trunk supports a select() like interface to determine which sockets are available for reading. With that code, you could implement the 10 socket readers in 1 thread instead of in 10. The interface returns the sockets which are ready for reading. If the timeout exceeds, an empty list is returned. The interface is called WAIT-FOR-INPUT.
The idea is that you only start reading the response until you have input on the socket available. I understand this is not exactly the same solution as the route you have taken, but it's available today on many more lisps than the 2 you implemented so far. Do you think this approach might work for you?
The only problem is that I fixed the LispWorks/Win32 code last weekend and haven't had the chance to commit it yet. (Meaning that I did implement: ECL/Unix, ECL/Windows, Allegro, SBCL/Unix, CMUCL, ArmedBear, CLISP, Clozure CL (aka OpenMCL). Douglas Crosher implemented Scieneer CL.)
I could use someone with a real life application to test the library.
bye,
Erik.