[Libssh] Minor problem with polling/EOF

[Matt Lawson]

> I just looked at your problem.
> I'd say "not a bug, a feature" :)
> When it happens, are you each time at EOF ?

Yes, every time it happens I am at EOF, but sometimes
I am able to reach EOF without experiencing the
problem (e.g. perhaps it makes a difference whether
the eof comes by itself, or at the end of some data)

> In fact, when designing the API, i considered that
> the poll "had to" 
> return a positive value when the end of stream
> comes, because i consider 
> the EOF like an important evenement.

Yes I understand, like a socket poll will trigger on
closed connections or errors, makes sense.

> Maybe it's wrong and should return 0 - at which case
> you'd HAVE to check 
> for EOF after each channel_poll() that returns 0.

Which is exactly what I'm doing now with my
workaround.

> If you have some pointers about what interface is
> used on other IO 
> libraries, i'm all interested.

Just my opinion, I can think of 2 ways:

Way #1:

- a positive value indicates bytes to read
- a zero indicates "something else", now call
additional functions such as channel_is_eof() to see
if it's something special, or just a case of no data

Actually this is exactly what I'm doing now, except
the  flag condition is ((poll is 1) && (read is zero))
instead of poll just being zero.

The channel_is_eof() would be a reasonable thing to
use, but since this function was hidden from the
application I figured I must be doing it "wrong"
somehow to have to expose that.

Way #2:
- a positive value from poll() indicates data to read
- a zero indicates no data but nothing unusual
- various negative values indicate EOF or error, with
possible other function calls to refine the exact
condition



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ