Hi, Erik
Very good, and it's my pleasure to have same thoughts with you:)
By the way, I should publish some news:
For the local binding patch, I've get contacted with the CMUCL
maintainer (Raymond Toy), and we were still talking about the local-
bind-patch on CMUCL mailing list. I think it's
> I think one of the design idea of usocket is just not use CFFI, and any
> non-lisp code. IOlib is another approach of Lisp networking, it has some C
> wrapper code to be used with CFFI.
Yes, basically I agree.
> Use select() or pool() will cause non_OS-portable code and other
> difficulties. I
Hi there,
I think one of the design idea of usocket is just not use CFFI, and
any non-lisp code. IOlib is another approach of Lisp networking, it
has some C wrapper code to be used with CFFI.
Use select() or pool() will cause non_OS-portable code and other
difficulties. I suggest not use
> Perhaps a portable interface to the select() and poll() functions would
> be better.
fyi, iolib exactly that: using cffi, it exposes the socket api.
--
attila
___
usocket-devel mailing list
usocket-devel@common-lisp.net
http://common-lisp.net/cgi-bi
On Sun, Jun 17, 2007 at 9:48 AM, Douglas Crosher <[EMAIL PROTECTED]> wrote:
> Hello Erik,
>
>>> Changing the wait-for-input-internal function to set a flag in the socket
>>> objects
>>> to indicate they are ready would avoid the need to cons up a list of
>>> ready sockets
>>> which can become very
