> > 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
> opera
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 appli
> 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 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.
>
> 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 t
* 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?
>
> 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
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'
> 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
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 o
> 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 reference
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 y
> -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 t
> 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 imp
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.
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.
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
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
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 rea
> 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
> sacrifi
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
> 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
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
> 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
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 docu
> 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.
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 non-bloc
> 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
28 matches
Mail list logo
