"Andreas Raab" <Andreas.Raab at gmx.de> wrote:
> Göran,
> 
> > (Andreas, you must be in Germany right? Normally the list is 
> > pretty dead when I am awake... :-))
> 
> You're right ;-)
> 
> > > > Then... you do not in fact signal the semaphore when there is 
> > > > no data - right? (I don't really know what your last line before
> > > > "return 0" does, is that the "arming" stuff? Hey, btw, the Unix
> > > > version returns -1 if the socket is not valid, not 0...)
> > > 
> > > Which is right. It means that the socket is broke, thus returning an
> > > error code (-1) instead of telling the client that there's simply no
> > > data available is the right thing to do.
> > 
> > Good.
> 
> Bad ... I just looked at the plugin side of it and it turns out that the
> code for receiveDataAvailable _cannot_ return an error code. The return
> code is converted into a boolean and any non-zero return value will be
> interpreted as "true". There ya go. Gotta check my own code now.

Ok, that might explain "dataAvailable" glitches we have seen
sometimes...
But perhaps not, I think we have seen those on Win32 too.

Anyway, I still don't understand why we set the pending notify on the
readSemaphore in the Unix code.
Ian hinted that I might remove that line and see what happens - but why
is it there in the first place? A typo? ;-)
And I still don't understand when the semaphore actually gets signaled
in the example I posted.

But I am too busy right now to try fiddling with the code - will try
more on friday. At home on Win32 and at work on Win2k it works though.

> Cheers,
>   - Andreas

Cheers, Göran

PS. To most people it hasn't been a problem that getData indeed
busywaits (even if it is very unnecessary) but we have multiple
processes running on the same priority and when one busywaits nobody
else gets to play. That was how we "found" the problem. DS