[usocket-devel] Re: IPv6 support in usocket

[Chun Tian (binghe)]

On 24/giu/2013, at 18:49, Tomas Hlavaty <tomas.hlavaty at knowledgetools.de> wrote:

> Hi binghe,
> 
> the portability layer lives in the package :iolib.usocket and implements the usocket api.  How would you implement and api without emulating another package's interface?  Isn't the api the package's interface? If the user loads iolib.usocket.asd, what else should he expect instead of usocket with all functionalities of usocket in it?

It works, but if you try to depend on another package which depend on the real usocket, you'll got conflicts.   Therefore such approaches cannot goes into Quicklisp as a common solution, I think.

> 
> iolib.usocket.asd creates an alias system and package so that users don't have to make any explicit code changes to their own code base.
> 
> yes, usocket is brilliant for covering the platforms where cffi and iolib are not available/desirable.
> 
> The problem with the wait-* functions is that they are inherently non-portable (posix specific) and also assume certain programming model which is so far incompatible with wide-spread common lisp libraries.  For example, I added a timeout argument to socket-accept so that hunchentoot can work without assuming posix (on winapi).  Going forward, it might be worth acknowledging different programming models and embrace them in the usocket api.

I don't quite under this part.  usocket's WAIT-FOR-INPUT, depends on select() on UNIX-like systems, and WSAEventSelect() on Windows. When setting the timeout to zero, it should equals to poll()/epoll().    It's design and firstly implemented by original usocket authors, I think it's quite useful.  The blocking approach is also supported when user can live with timeouts.

I guess you're using Hunchentoot with the usocket emulations based on IOlib, but you didn't implement WAIT-FOR-INPUT, right?   I think that's because IOlib never port their powerful I/O multiplexing interfaces to Windows, so far it only support three OS-provided functions: select (on general Unix), epoll (on Linux) and kqueue (on BSD systems). Maybe you should encourage IOlib author to support "WSAEventSelect", then you don't need to use a timeout arguemnt to socket-accept any more...

> 
> Cheers,
> 
> Tomas
> 
> On 06/24/2013 12:25 PM, Chun Tian (binghe) wrote:
>> Hi Tomas
>> 
>> I think it's not quite polite to directly emulate another package's interface (and creating other package's Lisp package), so you shouldn't expect after loading IOlib.usocket, you got a package "usocket" with all functionalities of usocket in it. However, with a slightly changed Lisp package name, the whole idea is possible, just like what CFFI tries to emulate UFFI  by using a separated system "cffi-uffi.asd".  Any way, this is something not cared by me, because I'm not the maintainer of IOlib.
>> 
>> What I cared is to make exist usocket users and applications live better without making any explicit code changes into their own code base. By using IOlib as a backend, usocket's WAIT-FOR-INPUT function now can directly use IOlib's strong I/O multiplexing facility and exceed the 512 fd limitation when using select().  I also care those platforms in which CFFI and IOlib is not available, so a plain usocket implementation is still needed.
>> 
>> On 24/giu/2013, at 17:56, Tomas Hlavaty <tomas.hlavaty at knowledgetools.de> wrote:
>> 
>>> Hi binghe,
>>> 
>>> you are welcome.  Both iolib and usocket seem to be under the MIT licence so I don't see a problem on that front.
>>> 
>>> However, shouldn't the code be merged into iolib only rather than merging it into both iolib and usocket?  The whole of the iolib winapi port makes it quite a lot of code.  It would be a shame to sacrifice the winapi part especially when usocket is all about portability API.
>>> 
>>> Also, as Anton pointed out, I find a separate system better solution than pushing a feature.  After all, usocket is an API. When implemented using iolib, why would there be a need to use any code from the original usocket?  At the moment we simply asdf-load :iolib.usocket only and all systems depending on usocket work as desired because the required usocket system and usocket:* stuff is in place.
>>> 
>>> Cheers,
>>> 
>>> Tomas
>>> 
>>> On 06/24/2013 11:33 AM, Chun Tian (binghe) wrote:
>>>> Hi Tomas
>>>> 
>>>> Thank you! Then I guess you wouldn't mind if I merge your work into usocket as the basis of the new IOlib backend? ^_^
>>>> 
>>>> --binghe
>>>> 
>>>> On 24/giu/2013, at 17:30, Tomas Hlavaty <tomas.hlavaty at knowledgetools.de> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> just in case it might be somehow interesting, we've had iolib.usocket system for quite some time in http://src.knowledgetools.de/tomas/winapi/index.html It is a simple usocket compatibility layer on top of iolib (also works on Windows winapi 32 and 64 bit).  Not sure what the ipv6 status is though as we don't use that.  IIRC I still need to implement translation of iolib conditions to usocket ones, but as a precondition for that is unifying conditions from iolib posix and winapi backends.  Otherwise, hunchentoot and cl-postgres work well on posix and windows using this compatibility layer.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Tomas
>>>>> 
>>>>> On 06/24/2013 11:12 AM, Anton Vodonosov wrote:
>>>>>> Hello.
>>>>>> 
>>>>>> 24.06.2013, 11:22, "Chun Tian (binghe)" <binghe.lisp at gmail.com>:
>>>>>>> To compile usocket with IOlib, user should push :usocket-iolib into their *feature* first.
>>>>>> I would like to propose to use some other solution than conditional controlling
>>>>>> compilation with *reatures*.
>>>>>> 
>>>>>> The disadvantage of the conditional compilation is that when my application loads the usocket
>>>>>> as a dependency, the application doesn't know how usocket will work, because it was dediced
>>>>>> when usocket was compiled (possible during load of some other application).
>>>>>> 
>>>>>> If you give little bit more details about he usocket-iolib functions, I can propose more concrete solutions.
>>>>>> Very possible the proposal will  be a separate ASDF system, usocket-iolib.
>>>>>> 
>>>>>> Best regards,
>>>>>> - Anton
>>>>>> 
>> 
> 
>