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

Kazunori Asayama asayama at sm.sony.co.jp
Tue Mar 11 16:09:17 EST 2008


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.

I think other cases are rare and so it is acceptable to 
require to call spe_stop_info_read in such cases.

> Maybe it would be better if  _event_spe_context_run() would empty the
> event buffers before starting the next spe program.

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.

> 
> 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



More information about the cbe-oss-dev mailing list