Why _ThreadProcessSignalsFromIrq() in new exception processing?

Joel Sherrill joel.sherrill at OARcorp.com
Fri Feb 7 18:38:34 UTC 2003



Sergei Organov wrote:
> 
> Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> > 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.
> 
> I'm lost. Please see below.
> 
> >
> > > > 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.
> 
> Now I'm totally lost. I'm looking at 20020807 snapshot now. The boolean
> variable exists and is used in all the BSPs and old/new variants. That's not a
> problem. There are, however, three BSPs that use it differently than others.
> These BSPs are: arm, i386, powerpc/new_exception_processing.
> 
> Please take a look, for example, into
> c/src/lib/libbsp/powerpc/shared/irq/irq_asm.S
> and
> c/src/lib/libbsp/powerpc/shared/irq/irq.c
> 
> Search for _ThreadProcessSignalsFromIrq there.
> 
> If you are saying that this handling is the only correct, then all other BSPs
> are broken?! I can't believe that, so the initial question remains (refer to
> the beginning of citations above).

Nothing looks broken in the
c/src/lib/libbsp/powerpc/shared/irq/irq_asm.S to 
me.  That code is honoring the internal RTEMS variable 
_ISR_Signals_to_thread_executing and running the post switch extension
to
let signal handlers run before the thread resumes its execution where it
was interrupted. If the x86 and arm do the same thing, then they are
right also. [I didn't look at them though.]

The other ports tend to return to _ISR_Thread_dispatch which calls
_Thread_Dispatch which does the same thing.

All looks fine to me.

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



More information about the users mailing list