From: <fa...@gm...> - 2005-09-27 19:29:11
Attachments:
sendto.diff
test-sockets.lisp
|
Ahem, sorry for re-sending this patch, but I got no feedback on my previous post. Is there anything that prevents my patch to sb-bsd-sockets from being included in a next sbcl 0.9.5.x ? It adds support for sendto, and fixes performance in recvfrom, too. Small test program included. It also includes some basic support for a rather generic type "iobuffer". It would be interesting to move this support to its own file. This support could then be built into it some better logic for character<->octet translation using external-format (I currently assume latin1), and made to be used in sb-unix and other similar places (I could be interested in doing that). [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu= nes.org ] Clothes make the man. Naked people have little or no influence on society. -- Mark Twain |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2005-09-27 19:44:37
|
=?ISO-8859-1?Q?Far=E9?= writes: > Ahem, sorry for re-sending this patch, but I got no feedback on my > previous post. Is there anything that prevents my patch to > sb-bsd-sockets from being included in a next sbcl 0.9.5.x ? I haven't had a chance to play with it yet, but for what it's worth, as a fairly heavy user of sockets, it looks good to me. -- /|_ .-----------------------. ,' .\ / | Free Mumia Abu-Jamal! | ,--' _,' | Abolish the racist | / / | death penalty! | ( -. | `-----------------------' | ) | (`-. '--.) `. )----' |
From: Nikodemus S. <nik...@ra...> - 2005-09-28 08:15:32
|
On Tue, 27 Sep 2005, [ISO-8859-1] Far=E9 wrote: > Ahem, sorry for re-sending this patch, but I got no feedback on my > previous post. Is there anything that prevents my patch to > sb-bsd-sockets from being included in a next sbcl 0.9.5.x ? > > It adds support for sendto, and fixes performance in recvfrom, too. > Small test program included. This part seems good to my socket-ignorant eye, with the exception of the documentation here: =2E.. much better if it is a (simple-array (unsigned-byte 8) (*)), because that's what's used internally and for any other type there will be lossy and/or buggy conversion. =2E.. 1) Don't expose internals in documentation. Say it is eg. fast instead. 2) The lossy/buggy comment is worrying. What sort of problems are there? Specific issues and the way they are handled should be mentioned. > It also includes some basic support for a rather generic type > "iobuffer". It would be interesting to move this support to its own > file. This support could then be built into it some better logic for > character<->octet translation using external-format (I currently > assume latin1), and made to be used in sb-unix and other similar > places (I could be interested in doing that). This part I've no idea about, given that I don't understand the use-cases. The documentation is also a bit vague (not that I've spend much time=20 trying to make sense out of it, but a glance over left my uncertain as to= =20 its purpose.) Compounded by the fact that adding an entirely new interface is a=20 higher-cost operation (vrt. future maintenance) and the missing=20 external-format support -- I'd suggest you resubmit the first parts=20 separately for a faster merge. The iobuffer stuff can then be dealt=20 separately. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |