Hi!

(Andreas, you must be in Germany right? Normally the list is pretty dead when I am awake... :-))

--- Andreas Raab <Andreas.Raab at gmx.de> wrote:
> Göran,
> 
> > 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.

> > The thing I don't understand with the Unix version is why we 
> > signal the readSemaphore (well, it's not an immediate signal,
> > it's a pending event - the semaphore will be signaled on the next
> > call to notify() - how/when that call is done I don't know but
> > since the semaphore does indeed get
> > signalled AFAICT it must have been called somehow...).
> 
> As I said in my last post, this is done from aioPoll() which is called
> from several places throughout the Unix VM. Go look at it.

Yes, I understood that I think. I just didn't see how it is being called between line 10-12 below
(obviously I haven't gone through aioHandle close enough or there is some other thread doing
things or what-the-heck-do-I-know-anyway):

1 :int sqSocketReceiveDataAvailable(SocketPtr s)
2 : {
3 :   if (!socketValid(s))
4 :     return -1;
5 :   if (SOCKETSTATE(s) == Connected)
6 :     {
7 :       if (socketReadable(SOCKET(s)))
8 :         return true;
9 :       PSP(s)->pendingEvents|= READ_NOTIFY;
10:       aioHandle(SOCKET(s), dataHandler, PSP(s), AIO_RW);
11:     }
12:   return false;
13: }


> > I mean... why? :-) Ian proposed I should just skip that line, 
> > which I will try out, but I would really like to know why it's
> > there from the beginning...
> 
> Which line?!

Line number 9 above. Ian wrote:
> I suggest you try commenting out the line
> 
>         PSP(s)->pendingEvents|= READ_NOTIFY;
> 
> and then run every socket test in your possession to see what works/breaks.

You wrote in your previous post:
> It appears to me that there must be some mismatch in
> aioPoll() and socketReadable(); from your example it looks like
> aioPoll() is calling the dataHandler() which signals the semaphore but
> socketReadable() returns false in response to the query for data.

Hmmm, again since I don't know enough about how the VM works, aioPoll() etc. I fumble in the dark
but my example (posted later - the workspace reproducable-problem code) didn't in fact have any
data coming in on the socket - the server just sits there silently. So... why did the
dataHandler() get called as a result of line 10 above? When stepping over (in the debugger)
#primSocketReceiveDataAvailable: in #waitForDataUntil: the readSemaphore gets an excess signal. I
interpreted that as if the primitive call did the signal. Hmmm, obviously I am wrong in that
conclusion - aioPoll() gets called by other Squeak processes or something, right?

> Cheers,
>   - Andreas

regards, Göran

=====
Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
"Department of Redundancy department." -- ThinkGeek

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/