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

[D. Herrendoerfer]

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 ? 

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

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