[Cbe-oss-dev] We must call spe_stop_info_read() after every spe_context_run()

[Kazunori Asayama]

D. Herrendoerfer wrote:
> On Tue, 2008-03-11 at 14:09 +0900, Kazunori Asayama wrote:
>> D. Herrendoerfer wrote:
>>> I am wondering if it might be better actually make the calling of
>>> spe_stop_info_read() after every spe_context_run() optional.
>>>
>>> Right now not reading the return value leads to the point where
>>> spe_context_run() stalls because it can't write the return value
>>> into the message pipe, and I think this is bad.
>> I don't think this is a big issue.
>>
>> Consider when spe_stop_info_t structure is written into the pipe.
>> There are following three cases.
>>
>>   1. the SPE program exits.
>>   2. a user defined signal is raised.
>>   3. an error occurs.
>>
>> In the case 1 and 3, typically, spe_context_run will never be 
>> called again during the life time of the context.
> 
> Right, but with people starting to write code designed to overcommit
> SPE resources or to use SPE code as a function we will start seeing
> case 2 a lot more frequently.
> 
>> I think other cases are rare and so it is acceptable to 
>> require to call spe_stop_info_read in such cases.
> 
> Yes, agreed. An option would be to document that it _MUST_ be
> called after every invocation of spe_context_run().
> 
>>> Maybe it would be better if  _event_spe_context_run() would empty the
>>> event buffers before starting the next spe program.
> 
> That is what I was thinking, If the user didn't care to pick up the
> buffer contents, then why hold on to it ? 

It is difficult that the library knows whether the user intends
to ignore the spe_stop_info_t or not because the SPE thread and the event 
loop thread may run asynchronously.

I think it should be possible that the user can decide the usage of 
the spe_stop_info_t by him/herself.

So I suggest adding a new flag of spe_context_create
(or spe_context_run) like SPE_NO_SPE_STOPPED_EVENTS so that user can 
explicitly disable raising SPE_EVENT_SPE_STOPPED events.

When a user receives SPE_EVENT_SPE_STOPPED events, I suppose the user 
need to get more details by using spe_stop_info_read to decide the 
next behavior of the event loop. So I think we can assume that in 
most cases if a user doesn't need spe_stop_info_read, he/she doesn't 
need SPE_EVENT_SPE_STOPPED events too.

What do you think about this solution?

> 
>> Such a change causes incompatible behavior with the current one 
>> and another problem can be introduced. In general, spe_context_run 
>> and spe_stop_info_read are called from separate threads.
>>
>> The spe_stop_info_t is written on the pipe only when the event 
>> feature is enabled; i.e. when an SPE context is created with 
>> SPE_EVENTS_ENABLE flag. Think about the following typical scenario 
>> to use the event. I think most programs which use the event have 
>> similar structure to this one:
>>
>>   A. Threads A[1]-A[n] execute SPE programs by calling 
>>      spe_context_run.
>>   B. Thread B has an event loop to fetch events from threads 
>>      A[1]-A[n] and process them. The spe_stop_info_read will be 
>>      called from this thread when SPE_EVENT_SPE_STOPPED events are  
>>      received.
>>
>> So if spe_context_run reads the pipe internally as you say, 
>> if the *next* spe_context_run is called by threads A[x] *before* 
>> thread B calls spe_stop_info_read, that spe_stop_info_read 
>> will stall.
> 
> Agreed. That's a pitfall. Would it make sense to limit the depth of the
> pipe to 2 entries ? The current one and the last event ? 
> Right now the system starts misbehaving after 2700 or so invocations
> so maybe we could overwrite events at some point.

See above.

> 
>>> Opinions please.
>> I suggest keeping the current behavior.
>> Or alternative is adding a new flag to the context creation flag,
>> so that programmers can make SPE contexts stop writting 
>> spe_stop_info_t to the pipe.
>>> Best regards,
>>> D.Herrendoerfer

-- 
(ASAYAMA Kazunori
  (asayama at sm.sony.co.jp))
t