Mikhail Gusarov wrote: > It says "there might be less than count bytes written". It does not > tell anything about blocking, so short writes should be handled as > well, but it is not related to blocking/non-blocking. > > >> Why a kernel can't block on read/write on blocking socket? > PS> Sorry, what? > > Socket is blocking. Why kernel can't block?
Ah - thanks for clarifying!
Because we used select() to predict the future:
--8<-- Linux select(2)
DESCRIPTION
select() and pselect() allow a program to monitor multiple file
descriptors, waiting until one or more of the file descriptors become
"ready" for some class of I/O operation (e.g., input possible). A file
descriptor is considered ready if it is possible to perform the corre‐
sponding I/O operation (e.g., read(2)) without blocking.
..
Three independent sets of file descriptors are watched. Those listed
in readfds will be watched to see if characters become available for
reading (more precisely, to see if a read will not block; in particu-
lar, a file descriptor is also ready on end-of-file), those in writefds
will be watched to see if a write will not block, and those in
exceptfds will be watched for exceptions. On exit, the sets are modi‐
-->8--
This is really the whole point of select().
> PS> Ok, for reading nbio solves the problem when an application wants
> PS> to use both a really problematic SSH fd and another very
> PS> unproblematic high throughput fd.
I was wrong here. Nbio is irrelevant for that problem. select()ing
allows the high throughput fd to still shoot data through, while the
slow SSH socket is processed when it is ready.
> PS> If there is no space at all select() should not indicate
> PS> writable. If there is little space, write() should return short.
>
> See the below for the SUSv3 excerpt.
>
> PS> If there was space, but then that changed into no space, isn't
> PS> select() just plain broken?
>
> There may be less space than needed.
Then write() should return short is my understanding. In practice
I've just dealt with short write() returns in my code using select()
on blocking sockets, and I never had a problem.
> PS> If select() returns readable there is data, why would there
> PS> suddenly not be data anymore?
>
> SUSv3: "A descriptor shall be considered ready for reading when a call
> to an input function with O_NONBLOCK clear would not block, whether or
> not the function would transfer data successfully."
>
> It does not tell anything about blocking sockets.
Wouldn't "an input function with O_NONBLOCK clear" fit for example a
blocking socket?
> It does not tell anything about blocking sockets.
- That's repetitive.
- And redundant.
- That's repetitive.
- And redundant.
(Bonus points if you know the TV show :)
//Peter
pgp5IUYcAFwkN.pgp
Description: PGP signature
_______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
