John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> >don't exactly help. I just don't understand a word of what you're trying
> >to say. It may be that I'm just no native speaker but I just can't
> >figure out what that is supposed to mean ;-(
> >
> >Cheers,
> >   - Andreas
> 
> Well there is always the source code to look at, both the mac and the 
> unix code, two different implementations in fact

Does the Unix code really count?  Problems keep cropping up.  I recall
it taking a few iterations to get basic things working at all once this
was all introduced, and now it is being reconsidered again.


> However I think what would be really interesting here is to change 
> both the smalltalk code and the vm code to use what Craig did in 
> Flow. Pass a method based semaphore down to the primitive call in 
> question. It gets signaled once, or never on a timeout condition. 
> Perhaps this is a cleaner solution.

Interesting.  Though it might lead to the VM needing lists of
semaphores, which is a good bit of complexity.  There should be a reason
before introducing it.  (Then again, I say the same thing about the
3-semaphores thing.  The performance arguments are extremely
nebulous.)


> >don't exactly help. I just don't understand a word of what you're trying
> >to say.
> 
> Well let's look at the bsd unix code. I see pendingEvents contains 
> the mask bits for the triggers, or my interest in having a semaphore 
> signaled. The Mac VM will buffer incoming data until squeak reads it, 
> so having the semaphore signaled a dozen times before we actually 
> read things is counter productive so a "trigger" or indicator to 
> indicate which semaphore should be signaled once was introduced, 
> perhaps passing a semaphore around might be cleaner?

If we signal at state *changes*, then it should accomplish the same thing
while simplifying the descriptions.  Basically, the VM will be tracking
its own triggers, but the documentation doesn't have to explain this.

Also, it should help to have the image drain the semaphore completely
instead of just removing one signal at a time.  Then excessive
signals become very cheap.



-Lex


PS -- it would be very nice if that document was linked from somewhere,
e.g. the Socket class comment.  Ignore me if I simply haven't looked
hard enough; I hadn't realized it was documented at all!