Hi again :)
* David Schwartz wrote on Mon, Sep 03, 2007 at 17:36 -0700:
sorry, seems I'm unable to get it (I read it several times :)).
2) The application calls 'write', expecting it to block until
all the data can be written.
yes, we already talked about. I still think that this
Consider a 'select' followed by a 'read' in another thread. Is
that the operation that shouldn't block or are the 'select' and
the 'read' unrelated?
If the read was started (called) after the select finished
(returned), then this read (and only this read) is the subsequent
operation. If
* David Schwartz wrote on Thu, Aug 30, 2007 at 13:44 -0700:
If the first byte (or any part of the buffer) could be
written instantly or (e.g. if no select returned ready before
:)) after some amount of time waited, write should return to
give the calling application the control.
I can
sorry, seems I'm unable to get it (I read it several times :)). I
think the select could (if needed) store some flag (associated
with some fd) to remember that it returned that read must not
block by guarantee. Maybe some list including all fds where
select returned this. Any OS function
* David Schwartz wrote on Wed, Aug 29, 2007 at 08:07 -0700:
and a blocking write should return as soon as at
least one byte has been written.
No. A blocking write should block until all the requested data cen be
written.
ahh, interesting. Why should it?
Because this is what
This is acceptable for Perl, but not for C :-) Even if most
people would want a write contradicting its man page, I'd still
consider it wrong :)
I don't follow you.
If you tried to write two bytes, why would you want to wait
until the first one could be written but not wait until the
Hi!
* David Schwartz wrote on Tue, Aug 28, 2007 at 08:56 -0700:
I think it is important to note that a blocking read usually
should return if one single byte is available (even if more had
been requested)
Correct.
and a blocking write should return as soon as at
least one byte has
Hi!
* David Schwartz wrote on Tue, Aug 28, 2007 at 08:56 -0700:
I think it is important to note that a blocking read usually
should return if one single byte is available (even if more had
been requested)
Correct.
and a blocking write should return as soon as at
least one
On Wed, Aug 29, 2007 at 08:07:04AM -0700, David Schwartz wrote:
Yes, and additionally, there may be implementations supporting a
select function but at the same time not even conforming the
standard, I think such `TCP stacks' exist.
BTW, which standard would it be, `4.4BSD'?
I'm talking
Actually, this page says:
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.
Right, that is a hypothetical concurrent read.
Is that not to say that if
Hi,
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
* Yves Rutschle wrote on Mon, Aug 27, 2007 at 16:10 +0200:
On Sat, Aug 25, 2007 at 12:47:57AM -0700, David Schwartz wrote:
Yes? If so, the above paragraph or something similar
should be documented
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
That is they never
Hello,
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
+1
Darryl Miles wrote:
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
That is they never disappear unless the application permits them too.
That is not only not implemented by any known
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steffen DETTMER
Sent: Tuesday, August 28, 2007 2:11 AM
To: openssl-users@openssl.org
Subject: Re: SSL_peek vs. SSL_pending...
I think it is important to note that a blocking read usually
should
David Schwartz wrote:
That is not only not implemented by any known implementation but quite
literally impossible. Please tell me what implementation guarantees that a
TCP 'write' after a 'select' hit for writability will not block.
This is no use, your asking me for references and I'm asking
David Schwartz wrote:
That is not only not implemented by any known implementation but quite
literally impossible. Please tell me what implementation
guarantees that a
TCP 'write' after a 'select' hit for writability will not block.
This is no use, your asking me for references and I'm
On Sat, Aug 25, 2007 at 12:47:57AM -0700, David Schwartz wrote:
Yes? If so, the above paragraph or something similar should be
documented somewhere important (e.g. the manpages).
That's one way to put what I'm saying. I agree it needs to be repeated more
often, that's one of the reasons I
Hmm...interesting. Essentially what you are saying is If one thinks
they need to use select() on a blocking socket, use non-blocking sockets
instead. And only when non-blocking sockets are insufficient, use
select() (i.e. to avoid a CPU-eating polling type of situation without
sacrificing
Here's what I want to do:
select() on the underlying socket.
IF select() says data is available to be read,
let OpenSSL manage processing that data but not block even if the
socket is blocking.
Check to see if SSL_read() will succeed instantly by calling SSL_pending().
IF SSL_pending()
What I want to know is how do I tell OpenSSL that it is okay to do some
processing of socket data but not block even with blocking sockets?
You are asking for the impossible. There is no way to be sure a socket
operation will not block other than to set the socket non-blocking. Much
code has
David Schwartz wrote:
What I want to know is how do I tell OpenSSL that it is okay to do some
processing of socket data but not block even with blocking sockets?
You are asking for the impossible. There is no way to be sure a socket
operation will not block other than to set the socket
MSDN Library documents select() as being exactly as I describe:
http://msdn2.microsoft.com/en-us/library/ms740141.aspx
(See the description of when readfds returns).
So now that the matter you describe has been cleared up, answer the
question.
You misunderstand the documentation. Nowhere
David Schwartz wrote:
MSDN Library documents select() as being exactly as I describe:
http://msdn2.microsoft.com/en-us/library/ms740141.aspx
(See the description of when readfds returns).
So now that the matter you describe has been cleared up, answer the
question.
You misunderstand the
Which part of For other sockets, readability means that queued data is
available for reading such that a call to recv, WSARecv, WSARecvFrom, or
recvfrom is _guaranteed not to block_. do you not understand?
It means a hypothetical concurrent call, not a future actual call.
There is simply no
David Schwartz wrote:
Which part of For other sockets, readability means that queued data is
available for reading such that a call to recv, WSARecv, WSARecvFrom, or
recvfrom is _guaranteed not to block_. do you not understand?
It means a hypothetical concurrent call, not a future actual call.
David Schwartz wrote:
Which part of For other sockets, readability means that queued data
is
available for reading such that a call to recv, WSARecv,
WSARecvFrom, or
recvfrom is _guaranteed not to block_. do you not understand?
It means a hypothetical concurrent call, not a future
David Schwartz wrote:
David Schwartz wrote:
Which part of For other sockets, readability means that queued data
is
available for reading such that a call to recv, WSARecv,
WSARecvFrom, or
recvfrom is _guaranteed not to block_. do you not understand?
It means a hypothetical concurrent call,
29 matches
Mail list logo
