On Fri, 18 Sep 2009, Peter Stuge wrote:
"A file descriptor is considered ready if it is possible to perform the
corresponding I/O operation (e.g., read(2)) without blocking."
and
"those in writefds will be watched to see if a write will not block"
from select(2) not only implies but specifies exactly that.
If that would be the case, as I already have explained, the operations in
blocking and non-blocking mode would be *identical* and you would gain nothing
by switching to blocking mode!
So instead of me repeating myself, let me instead ask you what the point is of
your blocking-mode questions (and not believing my responses)?
I find it a very strange concept if select() is saying that they will not
block. Have you seen it happen?
Yes of course. That's what blocking mode can cause. It happens.
Why? We already have a defined API, what's wrong with it?
Not the API but the implementation. If the implementation can be simplified
significantly by a change (or mere addition) to the API I think that it is
worthwhile.
"If" being the keyword there. How would using signals within libssh2 help
anything? To me, this just feels like you're taking stabs at things blindly in
the dark and then questioning if we shouldn't use that instead. What problem
do we solve by allowing libssh2 to cause SIGPIPE? I can tell you a lot of
problems it would bring.
I know that you are very cautious with API changes so it is possible that
you disagree. :)
I completely agree with your statement "If the implementation can be
simplified significantly by a change".
But I do not see how signals would provide anything that could even be called
a little simplified.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
