Daniel Stenberg wrote:
>> from select(2) not only implies but specifies exactly that.
>
> If that would be the case, as I already have explained, the
> operations in blocking and non-blocking mode would be *identical*
> and you would gain nothing by switching to blocking mode!
True if there would be no EAGAIN errors right now.
> So instead of me repeating myself, let me instead ask you what the
> point is of your blocking-mode questions
The point is that because io functions can be called at any time,
they can return EAGAIN, and the caller needs to spin on the call, it
seems that the library needs to keep some amount of extra state.
If io functions were only ever called when they should actually do
something however, there would be less state to keep and less
overhead.
> (and not believing my responses)?
I'm sorry, but the reason that I am sceptical is because you are
basically saying that select() is not reliable.
>> I find it a very strange concept if select() is saying that they
>> will not block. Have you seen it happen?
>
> Yes of course. That's what blocking mode can cause. It happens.
On what systems have you seen it? If open source, were there any
comments from upstream?
To me, the behavior you say is natural seems to be in direct conflict
with the documentation.
>> If the implementation can be simplified significantly by a change
>> (or mere addition) to the API I think that it is worthwhile.
>
> "If" being the keyword there. How would using signals within
> libssh2 help anything?
Sorry, no, a signal is not the goal and I would also prefer avoiding
signals. The goal is to keep minimal state and have zero overhead.
Blocking io would be the means.
> To me, this just feels like you're taking stabs at things blindly
> in the dark and then questioning if we shouldn't use that instead.
Sorry for not communicating more clearly. My train of thought starts
with libssh2 continuing to have unreliable io in spite of several
attempts at fixing it. I've looked a little bit at it, you've already
done several series of fixes, but problems persist.
Simpler state machines are easier to deal with and if code can be
simplified and overhead reduced at the same time I'm thinking it
might be a good idea to explore a different solution.
I do assume that select(), and WaitForOverlappedIo() or whatever it's
called for that matter :), are actually working according to
documentation, and it has been OK for me, but on the other hand my
experience is only from fairly friendly environments so maybe I've
just been lucky all this time. But that does rub me the wrong way..
--8<-- Linux select_tut(2) line 201..
Select Law
Many people who try to use select() come across behavior that is diffi‐
cult to understand and produces non-portable or borderline results.
For instance, the above program is carefully written not to block at
any point, even though it does not set its file descriptors to non-
blocking mode.
-->8--
(There's a short example earlier in the page, which is what I've
successfully based my programs on. It used to be in select(2).)
As I understand you, you claim that document to be in error, in
particular the "not to block at any point" part?
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
