Why _ThreadProcessSignalsFromIrq() in new exception processing?

[Joel Sherrill]

Sergei Organov wrote:
> 
> Valette Eric <eric.valette at free.fr> writes:
> > Sergei Organov wrote:
> > > Could somebody please explain what is the purpose of call to
> > > _ThreadProcessSignalsFromIrq() in the new-exception-processing from the
> > > shared_raw_irq_code_entry? Should it be implemented in the old exception
> > > processing for proper RTEMS behavior?
> >
> > I guess, you will not get fully working posix signaling without doing this
> > (look at pthreadkill or signalsend). This block of code is used to trigger a
> > processing on the newly switched thread that end up calling
> > _API_extensions_Run_postswitch.
> 
> "Guess" is better than nothing :-) Does it mean I'm OK even without the call
> if I don't use pthreads?

No.  Eric's description was correct but it is also be accounting 
Classic API signals.  And POSIX signals can be sent to Classic tasks.
There are in fact the mechanism used to implement Ada interrupts and
this path is critical for handling FPU exceptions in Ada.

> > NB : The code was already there on ix86 when I implemented the new exception
> > model I just keeped it. When going to PPC, the call was missing so I added
> > it.
> 
> So maybe those one who wrote it initially for ix86 will comment more...

I'm commenting on the general use of the single boolean variable that is
set to indicate that a signal has been sent to the currently executing
thread.

> > In most advanced RTOS, there are things that should be done on the current
> > thread that have been trigerred as the result of a system call from isr and
> > that must be deffered until the thread runs again...
> 
> Sorry, don't quite understand. Care to give an example scenario when it is
> required? I feel myself rather bad without understanding of how things are
> supposed to work.
> 
> > In that case having a context is very usefull. I wanted to use it to
> > implement a call to debugger from keyboard in particular....
> >
> > > BTW, is the new exception processing model documented somewhere as this
> > > call is not the only violation of the old documentation describing how
> > > exceptions/interrupts should be handled by BSPs?
> >
> > If documentation is not accurate, trust the code.
> 
> The trick is to find out whether the documentation or the code is not accurate
> and if the former, which particular reincarnation of the code should be
> trusted ;-)
> 
> > If old code is broken, do not stick to it :-)
> 
> I don't as soon as it is indeed broken ;-)
> 
> BTW, its the new code for PPC that seems to be broken *for me*. I use EABI
> (-meabi -msdata=eabi) heavily, EABI requires r2 to point to '.sdata2' section,
> but the raw irq code seems to clobber it :-(
> 
> --
> 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