[Libssh] Minor problem with polling/EOF

[Aris Adamantiadis]

Matt Lawson a écrit :
>>> does Rodolphe Rocca's patch posted on this list
>>> correct your problem ?
> 
>> a while, as it was a slippery bug.
> 
> Ha!  That didn't take long...  What I decided to do
> was rebuild the library based on yesterday
> (2008-03-04) svn snapshot.  So all those patches
> should be incorporated, as well as quite a lot of
> other changes since the 0.2 release (maybe a 0.2.1 or
> 0.2a release would be nice?)
> 
> Well that didn't fix my bug.  It behaves the same as
> before.  What I do is this:
> 
> pollRc = channel_poll(channel,0);
> if (pollRc>0) {
> rc=channel_read_nonblocking(channel,buf,pollRc,0);
> // WHOOPS!!  pollRc=1, rc=0
> }
> 
> I can do that nonblocking read till the cows come home
> and the state never changes, always polls 1 but reads
> zero.  During this condition, channel_is_open()
> indicates the channel is still open (!=0) but
> channel_is_eof() indicates that it is at EOF (!=0)
> 
> My workaround is to expose the channel_is_eof()
> function, as this is the only way I know that the
> channel is [should] close.

I just looked at your problem.
I'd say "not a bug, a feature" :)
When it happens, are you each time at EOF ?
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.
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.
In fact, the poll() system call on unix is completely different and less 
ambiguous.

It's an interesting question, i guess the good solution is the one that 
is consistent with the documentation. And the documentation doesn't 
explain that strange behaviour, so it's all my fault, sorry :)

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

Regards,
Aris