Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Sergei Organov]

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?

-- 
Sergei.