hi!
i have two changes planned:
1) use babel for string encoding/decoding ( http://common-lisp.net/~loliveira/soc07/babel/ ). the rationale is that it's a very nice cross platform unicode lib which is also very fast. Marijn, i hope you will not take it as offense! i know trivial-utf8 is your work, but i hope the speed and the de facto standardness of babel compensates. (Luis will give babel more publicity in the next weeks, but it's available for months now and i'm using it without problems).
2) use iolib for the socket code. i would like to do that because we are experiencing problems when dealing with sockets on sbcl when the system is under heavy load. another reason is that iolib is another nice piece of code, although its also more heavyweight then usocket and also posix-only (currently). i know you prefer simple libs, just like with ironclad/md5, but we need stability and this seems to be the simplest way to achive it.
what do you think of these changes?
Hi Attila,
About the encoding -- don't worry about ditching trivial-utf-8, if there is a faster and more general alternative that's cool. I don't see any functionality for writing directly to a stream in it though, but maybe I didn't look hard enough. Perform some benchmarks to prove that babel actually speeds things up before building a patch.
I didn't know iolib. It looks cool -- but I'm not okay with making postmodern posix-only. If you can find a way to make the socket library 'pluggable', that would be cool... but then we're writing a wrapper around socket wrapper libraries, which is a bit screwy. Have you looked deeply in the problems you're having with usocket? Might they be fixed by patching usocket?
Cheers, Marijn
About the encoding -- don't worry about ditching trivial-utf-8, if there is a faster and more general alternative that's cool. I don't see any functionality for writing directly to a stream in it though, but maybe I didn't look hard enough. Perform some benchmarks to prove that babel actually speeds things up before building a patch.
ok. i'm waiting for Luis to push some of his changes, and after that i'll add buffered stream writing capabilities if it's not among the new patches.
I didn't know iolib. It looks cool -- but I'm not okay with making postmodern posix-only. If you can find a way to make the socket library 'pluggable', that would be cool... but then we're writing a wrapper around socket wrapper libraries, which is a bit screwy. Have you looked deeply in the problems you're having with usocket? Might they be fixed by patching usocket?
the problem is with sb-bsd-sockets. but even if it were working fine then usocket would be missing api for timeouts. my problem is that sometimes the connection is dropped (no idea why, there's no error in the postgres log), but when it happens in the wrong phase then the CL:CLOSE call hangs in TRY-TO-SYNC forever. my current fix is a local kludge patch that uses sbcl's WITH-TIMEOUT directly.
i'll try to make iolib compile-time pluggable and if it's not too kludgy then i'll record it and report back.
happy hacking,
i'll try to make iolib compile-time pluggable and if it's not too kludgy then i'll record it and report back.
I was thinking about this today -- maybe it would be easiest to implement a USocket backend based on IOLib, with dynamic variables to configure things that the USocket interface does not incorporate (such as timeouts). That way, Postmodern would not have to be changed, and the same code could be used in other projects that use USocket. You could even ask Eric if he'd be interested in incorporating such things in the general USocket interface.
Marijn
postmodern-devel@common-lisp.net
-
Attila Lendvai -
Marijn Haverbeke