Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Joel Sherrill]

Sergei Organov wrote:
> 
> Valette Eric <eric.valette at free.fr> writes:
> > Joel Sherrill wrote:
> > > Many ports actually have a label "_ISR_Thread_Dispatch" which is
> > > the point to which _ISR_Handler returns when a onctext switch or signal
> > > evaluation is needed. The typical implementaiton of that pushes some
> > > registers, calls _Thread_Dispatch, pops them and returns. This way
> > > there is a simple, single patch out of the ISR for all cases requiring
> > > OS evaluation.
> >
> > But, comming back to the push of a thread context and the performance I think
> > :
> >
> >       1) The path to switch should be as fast as possible and should not
> >          require pushing any other registers than the C scratch registers (+
> >          some unavaoidable one). This path is critical for all wakeup from
> >          ISR primitives (mtext/sem V, eventPost, ...,
> 
> Agreed.
> 
> >
> >       2) The path for software exception is not critical from a performance
> >          point of view and having a context realy helps in a lot of
> >          situation,
> 
> Here I don't agree. Who said that the particular path in which you are
> inserting "software exception" code is infrequent? You already stated a few
> times it is documented to be infrequent. Where? In the comments? Just telling
> it's infrequent doesn't make it infrequent. From Joel's explanations I've drawn
> a conclusion that it could be rather frequent if application uses POSIX
> signals heavily. Am I mistaken?

Not if the signals are sent from ISR handlers. For an Ada application
using
Ada language interrupts, I think this could definitely be fairly
frequent.

> --
> Sergei.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985