Re: more convenient :nodeay option - :if-supported

Anton,

I committed your patch to usocket's trunk, thanks a lot!

-Hans

On Fri, Jan 20, 2012 at 11:23 PM, Anton Vodonosov
<avodonosov@...> wrote:
> Hello.
>
> Today socket-connect option :nodelay if specified accepts T or NIL. And whatever value is passed,
> socket-connect signals the UNSUPPORTED exception on implementations where it is not
> possible to control the socket no-delay property.
>
> This dooms any usocket-using code which wishes to use :nodelay to be broken on
> implementations where it is not implemented (e.g. CLISP, CMUCL, ...).
>
> I think in most cases users would prefer "no delay if possible, otherwise just work as you can"
> behavior. For example drakma. On the implementations where it is possible, it will have
> maximum performance by specifying no-delay. But on other implementations it is desirable
> to work on usual socket.
>
> To support this in backward-compatible fashion I propose to introduce another value
> for the :nodelay option. :nodelay :if-supported. The meaning is obvious.
>
> Please see the patch attached. It is tested (by changing drakma to use :nodelay :if-supported)
> on all the implementations available to me: Allegro, CCL, CLISP, SBCL.
>
> Can't test on ECL and ABCL because of other obstacles (the last public release of ECL
> can't comile babel, and ABCL can't load cffi).

more convenient :nodeay option - :if-supported

Hello.

Today socket-connect option :nodelay if specified accepts T or NIL. And whatever value is passed,
socket-connect signals the UNSUPPORTED exception on implementations where it is not
possible to control the socket no-delay property.

This dooms any usocket-using code which wishes to use :nodelay to be broken on
implementations where it is not implemented (e.g. CLISP, CMUCL, ...).

I think in most cases users would prefer "no delay if possible, otherwise just work as you can"
behavior. For example drakma. On the implementations where it is possible, it will have 
maximum performance by specifying no-delay. But on other implementations it is desirable
to work on usual socket.

To support this in backward-compatible fashion I propose to introduce another value
for the :nodelay option. :nodelay :if-supported. The meaning is obvious.

Please see the patch attached. It is tested (by changing drakma to use :nodelay :if-supported)
on all the implementations available to me: Allegro, CCL, CLISP, SBCL. 

Can't test on ECL and ABCL because of other obstacles (the last public release of ECL
can't comile babel, and ABCL can't load cffi).

Best regards,
- Anton

_______________________________________________
usocket-devel mailing list
usocket-devel@...

Re: Unit tests failures on different lisps

Hi, Anton

Thanks for reporting this regression, I'll fix this in next USOCKET release. (and sorry for late response)

Regards,

Chun Tian (binghe)

在 2011-12-29，10:29， Anton Vodonosov 写道：

> 
> 
> 29.12.2011, 03:07, "Anton Vodonosov" <avodonosov <at> yandex.ru>:
>> Some of the failures are probably bugs in tests, but other seems to be bugs in usocket itself.
>> For example CCL on Windows:
>> 
>>   Read error between positions 195 and 295 in C:/Users/anton/quicklisp/dists/quicklisp/software/usocket-0.5.4/vendor/ccl-send.lisp.
>>   Unhandled ERROR is signaled: Foreign function not found: WIN64::|send|
>> 
> 
> BTW, this particular error seems to be a regression on CCL 1.7 Windows.
> 
> I just added test results for more CCL versions. You may compare CCL windows version:
> 1.7 64bit and 32bit have this error, but 1.6 64bit does not.
> 
> _______________________________________________
> usocket-devel mailing list
> usocket-devel <at> common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel