A IOlib backend of USOCKET?

Hi,

I'm thinking of writing a IOlib backend for USOCKET.  There's no doubt that IOlib is a better choice of CL
networking library for people whom love (or at lest not hate) loading CFFI, C-based DLLs and lots of third
party packages into their CL platforms.  And, IOlib's io.multiplex package is also a better way to do
"select" on multiple sockets.

In my idea, there will be a new "usocket-iolib.asd" system, which depends on IOlib's networking part, and
will load USOCKET core plus a special backend for IOlib. This backend just assume IOlib is a new platform,
and use IOlib's networking API to implement all USOCKET API.

Will this idea be helpful for any USOCKET user?

Regards,

Chun Tian (binghe)

_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

Re: A IOlib backend of USOCKET?

On Mon, Oct 4, 2010 at 15:01, Chun Tian <binghe.lisp@...> wrote:
> I'm thinking of writing a IOlib backend for USOCKET.  [...]

> Will this idea be helpful for any USOCKET user?

It will not be helpful to me at the moment, but I do like the idea -
It would be particularily nice if it would be easily possible to use
USOCKET and still use the I/O multiplexing facility of IOlib (i.e. run
some USOCKET based libraries and add more file descriptors to the I/O
multiplexer without having to resort to threads).

-Hans

Re: A IOlib backend of USOCKET?

_______________________________________________
usocket-devel mailing list
usocket-devel@...
http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel

Re: A IOlib backend of USOCKET?

Vsevolod Dyomkin <vseloved@...>
writes:

> It seems to me, that usocket and IOlib are two projects of mostly the
> same abstraction level, that implement alternative approaches:
> Lisp-runtime-backed and OS-backed sockets.  And it would be better, if
> the alternatives both remain.

Indeed. However you should consider the integration of libraries written
to use these competing libraries.

We had the case with UFFI and CFFI too.  There's a UFFI/CFFI
compatibility package to allow libraries using the UFFI API to work with
CFFI.

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Wait-for-input/socket-accept for sbcl/win32

Hello.

Dmitry, I've tried the patch. It works, but not always. Sometimes I get this error: 

Socket error in "accept": 0 (Operaction completed successfully.)
[Condition of type SB-BSD-SOCKETS:SOCKET-ERROR]

Backtrace:
0: (SB-BSD-SOCKETS:SOCKET-ERROR "accept")
1: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-ACCEPT (SB-BSD-SOCKETS:SOCKET)) #<unavailable
argument> #<unavailable argument> #<SB-BSD-SOCKETS:INET-SOCKET 0.0.0.0:4242, fd: 9 {248303C9}>)
2: ((SB-PCL::FAST-METHOD USOCKET:SOCKET-ACCEPT (USOCKET:STREAM-SERVER-USOCKET)) #<unavailable
argument> #<unavailable argument> #<USOCKET:STREAM-SERVER-USOCKET {248309F9}>)[:EXTERNAL]
3: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS (HUNCHENTOOT:ACCEPTOR)) #<unavailable
argument> #<unavailable argument> #<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>)
4: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK365]370))
5: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
6: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]300))
7: (SB-THREAD::CALL-WITH-MUTEX ..)
8: (SB-THREAD::INITIAL-THREAD-FUNCTION)

I am testing it by running hunchentoot-1.1.0 on windows, with the recent SBCL+threads (the binay
downloaded from http://dmitry-vk.livejournal.com/34529.html?thread=135905#t135905).

I am not really sure if it's a bug in Usocket, or in SBCL.

Best regards,
- Anton