RE: my action item for explaining semantics of notify callbacks in SCE-MI pipes

John,

>>>>How about when the buffer implementing the pipe is full?
>>>
>>>johnS:
>>>Precisely. i.e. a blocking function will see a try function
>>>fail due to a full (or empty) pipe and so will yield at that point.
>>>Until it can try again. Again, refer to the example in the
>>>spec for how this is done.
>>
>>
>>  [Shabtay]
>>
>> John, I want to be very precise about the conditions. Fullness of
>> emptiness of the buffer by your proposal does not cause either yield
or
>> callback to be called. Only the fact that #elements in the pipe have
>> changed established the criteria for the callback to be called, and
it
>> is the blocking send on full buffer or blocking receive on empty
buffer
>> that causes the yield (among the other causes we discussed).
>>
>> Please confirm.
>
>johnS:
>Not entirely true.
>
>Detection of fullness (or emptiness) will ultimately cause
>a blocking send (or receive) operation to yield.
>
>In the process of trying to move a requested # elements,
>a blocking call will do partial updates of the pipe between
>yields. When this happens it is important to notify the other
>end since this represents a change in state.
>
>
[Shabtay] I agree that IF blocking call detects fullness (or emptiness),
it will cause and yield that will result in partial updates, etc.

I think however that you almost look at this from a blocking call point
of view, while I am analyzing the case subject to either using non
blocking or using blocking. Is this legitimate?

So obviously input pipe empty detected by a blocking receive call will
cause a yield. However if the user chose the try_receive call which
failed, the actual detection of the buffer being empty does NOT cause a
yield. 

So please look again and let me know if you still disagree with what I
said above.




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.