Costin Manolache wrote:
Ok, so let me double check: the low level socket in sandbox is allways
read
after a poll() / select(),
and never with a blocking read() ?
huh? :)
After the poll(): the Comet servlet, in a tomcat thread will be able
to call
read() in the input
stream, and that will return data or 0 if no more data is available (
or -
call isReadable() and then read(),
or whatever else - but the socket will not be put in blocking mode ) ?
and some more huh :)
it is an implementation detail if the socket is blocking or non
blocking, and has nothing to do
with read() returning 0 or not.
now we are talking about the implementation, not the API. I can
implement inputstream.read() to return 0 on both blocking and non
blocking sockets.
btw, for the NIO connector, we only have non blocking sockets, the API
is an abstraction from the socket layer,
If this is true for sandbox - big +1.
not sure how the above relates to sandbox or trunk, since they use the
same sockets the same way.
Filip
Costin
On 6/15/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Filip Hanik - Dev Lists wrote:
> Please note, that neither Remy nor I have yet really talked about non
> blocking reads, so you might think sandbox is non blocking, well it is
not.
> It is buffering, but not non blocking. a true non blocking read, would
> require a rewrite of all the buffer filters to keep state between read
> invocations.
It is non blocking, as the low level read is always non blocking (in the
sandbox design).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 6/13/2007 12:50 PM
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]