David Schwartz wrote:
God I hope so.. I'm right in the middle of trying to get this
non-blocking stuff to work consistently (with a timeline fast
approachingarg!) and I can't tell if it's something I am doing wrong
and what exactly that is. Too many variables to be easy.
If you
On Thu, Jun 22, 2006 at 10:24:02AM -0700, David Schwartz wrote:
> (combined responses)
>
> > What is true for two stacked layers, maybe false for one.
> > (and the other way round).
>
> No standard guarantees that you are only dealing with one layer. In
> fact,
> in the Windows world, mul
(combined responses)
> What is true for two stacked layers, maybe false for one.
> (and the other way round).
No standard guarantees that you are only dealing with one layer. In
fact,
in the Windows world, multiple layers (hidden from the programmer) are
common thanks to LSPs. (And yes,
Darryl Miles wrote:
David Schwartz wrote:
I don't get it.
DS
Ah, finally something concrete.
Hey thats ok; sit back and relax. I'm sure a patch is on its way.
God I hope so.. I'm right in the middle of trying to get this
non-blocking stuff to work consistently (with a timeli
Hello,
> > No, of course no. In this context we are talking of kernel/system
> > implementation of select()/read() and you mix this with SSL.
>
> Because it demonstrates precisely the problem. The 'select' function
> has no
> way to know what type of read function will follow, and there are
David Schwartz wrote:
I don't get it.
DS
Ah, finally something concrete.
Hey thats ok; sit back and relax. I'm sure a patch is on its way.
Darryl
__
OpenSSL Project http://ww
(combined responses)
> No, of course no. In this context we are talking of kernel/system
> implementation of select()/read() and you mix this with SSL.
Because it demonstrates precisely the problem. The 'select' function
has no
way to know what type of read function will follow, and the
Alain Damiral wrote:
I'm wondering if it would not be highly appropriate to have an
'SSL_select' call defined by OpenSSL to have all operations on sockets
fully encapsulated and allow to reach the desired behaviour without
short-circuiting the layer approach... (it would provide similar
behav
David Schwartz wrote:
On Thu, 22 Jun 2006, David Schwartz wrote:
Bingo! And work may or may not translate into application data.
I thought that a recv on a blocking socket returns immediately after it
was able to do some work, no matter whether it resulted in receiving any
actual da
Hello,
> >* A readability event can disappear (after it has been first indicated
> >by poll/select and no read() family of functions have been called,
> >recvmsg()/recv() etc...
>
> >* A writability event can disappear (after it has been first indicated
> >by poll/select and no write() family of f
On Thu, Jun 22, 2006 at 07:35:15AM -0700, David Schwartz wrote:
> Since 'select' does not guarantee that a subsequent read operation won't
> block (since it can't even know what operation that's going to be), the
> subsequent read operation (which was 'SSL_read') blocked. That's because
> SS
Hello everybody !
David Schwartz wrote:
Since 'select' does not guarantee that a subsequent read operation won't
block (since it can't even know what operation that's going to be), the
subsequent read operation (which was 'SSL_read') blocked. That's because
SSL_read blocks for *applica
> >Same thing, no guarantee about what an actual future operation will
> > do. By
> > "would not block", they mean a hypothetical operation taking place at
> > the
> > time the indication is given to you.
> No. That's stupid. It's useless.
Not at all. It's the same as every other s
>Same thing, no guarantee about what an actual future operation will
do. By
> "would not block", they mean a hypothetical operation taking place at
the
> time the indication is given to you.
No. That's stupid. It's useless. By 'would not block' they mean 'if
nobody else messes with the d
> No, not "they mean", you have no authority to tell what "they mean".
> You have only authority to tell what is your interpretation
> of this text.
> Only authors may tell what "they mean" (are you one of them ?)
What? I presented an argument to show that they must mean this. You
snippe
> On Thu, 22 Jun 2006, David Schwartz wrote:
> > Bingo! And work may or may not translate into application data.
> I thought that a recv on a blocking socket returns immediately after it
> was able to do some work, no matter whether it resulted in receiving any
> actual data (e.g. socket clo
Hello,
> > For short:
> >
> > 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.
> > (The function might return data, an end-of-file indication,
> > or an er
On Thu, 22 Jun 2006, David Schwartz wrote:
>
> Bingo! And work may or may not translate into application data.
I thought that a recv on a blocking socket returns immediately after it
was able to do some work, no matter whether it resulted in receiving any
actual data (e.g. socket closed).
> If we are talking about standards, maybe you should read new releases
> of documents which you are citing as an authority. From 1997 to 2004
> many things changed:
> http://www.opengroup.org/onlinepubs/009695399/functions/select.html
Nothing that bears on this issue.
> For short:
>
> A
Hello
> This would be a valid argument if the standard didn't specifically
> provide
> us a way to get the exact guarantee you want. It's this simple:
>
> 1) You need a particular guarantee, specifically, that a 'read' won't
> block.
>
> 2) The standard provides you a clear way
Combined replies.
> Maybe we should look on other papers, for example part of select(2)
> man page from hpux 11.23:
>
> Ttys and sockets are ready for reading or writing, respectively, if a
> read() or write() would not block for one or more of the following
> reasons:
> + input data is avai
Hello,
> > David,
> > Please post a link to a manpage or other documentation that
> > justifies your
> > description of select.
>
> I posted a link to the SuSv2 description of 'select'. There is no
> guarantee
> there that a future operation will not block.
> http://www.opengroup.org/online
Hello,
> > David,
> > Please post a link to a manpage or other documentation that
> > justifies your
> > description of select.
>
> I posted a link to the SuSv2 description of 'select'. There is no
> guarantee
> there that a future operation will not block.
> http://www.opengroup.org/online
> David,
> Please post a link to a manpage or other documentation that
> justifies your
> description of select.
I posted a link to the SuSv2 description of 'select'. There is no
guarantee
there that a future operation will not block.
http://www.opengroup.org/onlinepubs/007908799/xsh/sel
24 matches
Mail list logo
