On Sat, 23 Jan 2010, Lawson wrote:
> I'm looking for a common denominator that can be re-used. Yes NSS is built
> on top of NSPR.
Right, but building a lib on top of NSPR doesn't necessarily mean that the lib
works automatically fine just because NSPR happens to be fine.
> If it sounds trivial and you don't see the value that's fine, I may do it
> for my own use anyway. But the difference is the amount of [re-]testing I
> have to do to make sure a product is really behaving reliably.
You can't avoid that re-testing just because they all use the same socket or
portability abstraction. They already use the same libc and that doesn't help
you much either.
> Another thing you could do is do a select() on all of them at once to see if
> any of them are ready to talk. As it is now, different socket types
> (typically) each have their own select() that are incompatible.
Yeah those things are really terrible (and was one of the reasons why I once
upon the time didn't go with libssh). I claim good network-related libs
provide access to the sockets in a way so that you can select() on them.
> In my initial tests of libssh2 it wasn't long before I found myself stuck in
> _libssh2_wait_socket (I think that's the name) without a timeout (it
> *almost* implemented a timeout! :) So probably nothing is perfect.
Did you really use it non-blocking then? That function is used internally in
the lib for waiting for socket actions and that implies blocking. But yes,
when using libssh2 in a blocking mode we don't really have many ways to
configure timeouts (yet).
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2010-01-23