Daniel Stenberg wrote:
> Not at all. The socket being writable according to select() doesn't
> imply that a write() or send() in blocking mode will return
> immediately.

I think that

"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.


> Blocking mode causes these functions to block at times, it's not
> too strange a concept.

I find it a very strange concept if select() is saying that they will
not block. Have you seen it happen?


[..signals..]

> 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.

I know that you are very cautious with API changes so it is possible
that you disagree. :)


But - if send() actually works like write() and returns short just
like write() there is no need to think about signals, and blocking
io is still an option.


//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Reply via email to