[usocket-devel] Re: Fwd: [usocket-cvs] r245 - usocket/trunk/backend
Chun Tian (binghe)
binghe.lisp at gmail.com
Wed Jul 23 16:50:19 UTC 2008
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 possible to merge my
CMUCL patch.
For the UDP patch [1,2] (which the first reason I go into your life),
Now I have a portable UDP server code. It's quite easy to wrote using
UDP local-binding, wait-for-input, and socket-receive/socket-send. I
don't know when you'll have time to look it and merge it, but I can
wait:)
--binghe
[1] https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp/trunk
[2] http://www.cliki.net/usocket-udp
在 2008-7-23,下午9:06, Erik Huelsmann 写道:
>> 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 suggest not use them directly... usocket should
>> keep it
>> simple, and shouldn't depends on CFFI, or any other ASDF package.
>
> And here, I agree too. However, some people have suggested that
> usocket could incorporate an alternative backend which is built
> 'closer to the OS', for example using CFFI.
>
> Even though I will not be building such a backend myself, I can
> definitely see why anyone would want to create it. And as such, when a
> maintainer pops up for the task, I'll happily integrate the
> contribution (and sustained maintenance!) into the project.
>
> I hope that we may see a contribution like this some time in the
> future (ie a contribution specifically targetted at performance).
>
> Bye,
>
> Erik.
More information about the usocket-devel
mailing list