[Xenomai-help] Signals

[Xenomai-help] Signals

[Kent Borg]

Thanks for the news that gdb should just work.

Now I am wondering about signals.  I want to be able to send a regular
Linux signal to a userland realtime process.  Do I use the regular
signal() to install a signal handler?  When would I use
rt_task_catch() and rt_task_notify()?

What about multiple threads?  I have 2 threads running.  It seems that
the thread that called signal() is the one landing in the handler
routine.  I would like to set some flags for the second thread to see,
so it can cleanup things before quiting, but it seems that my second
thread isn't running after I send the signal.  I also think I am
corrupting something, because if I set up a loop that launches and
kills my program, my machine freezes up after a dozen cycles.  I
commented out most of my guts and it still freezes up.


Thanks,

-kb

Re: [Xenomai-help] Signals

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Kent Borg wrote:
> Thanks for the news that gdb should just work.
> 
> Now I am wondering about signals.  I want to be able to send a regular
> Linux signal to a userland realtime process.  Do I use the regular
> signal() to install a signal handler?  When would I use
> rt_task_catch() and rt_task_notify()?

Those function are - in contrast to what to doc states - not yet
available in userspace. So far Xenomai is lacking the infrastructure to
deliver hard-RT signals to userspace threads, only the Linux signals are
passed as usual.

> 
> What about multiple threads?  I have 2 threads running.  It seems that
> the thread that called signal() is the one landing in the handler
> routine.  I would like to set some flags for the second thread to see,
> so it can cleanup things before quiting, but it seems that my second
> thread isn't running after I send the signal.  I also think I am
> corrupting something, because if I set up a loop that launches and
> kills my program, my machine freezes up after a dozen cycles.  I
> commented out most of my guts and it still freezes up.

Signals in multithreaded applications are tricky in general, even
without Xenomai. You may try to play with pthread_kill and
pthread_sigmask to control which thread receives a specific signal.

When the signal receiver is a Xenomai thread, the usual things happen:
blocking on RT-resources is cleared, the thread is migrated to secondary
mode, and the signal handler is invoked as one expects.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-help] Signals

[Kent Borg]

On Wed, Jan 25, 2006 at 09:20:28PM +0100, Jan Kiszka wrote:
> > rt_task_catch() and rt_task_notify()?
> 
> Those function are - in contrast to what to doc states - not yet
> available in userspace.

No wonder information on them is so sparse.

> So far Xenomai is lacking the infrastructure to
> deliver hard-RT signals to userspace threads, only the Linux signals are
> passed as usual.

But they are passed, that is good.

> Signals in multithreaded applications are tricky in general, even
> without Xenomai. You may try to play with pthread_kill and
> pthread_sigmask to control which thread receives a specific signal.

I have a very simple architecture, one thread is launched by regular
means, is launches the RT thread.  It is the parent thread that
registers for the signal and (I think!) it is the one that gets the
interrupt.

> When the signal receiver is a Xenomai thread, the usual things happen:
> blocking on RT-resources is cleared, the thread is migrated to secondary
> mode, and the signal handler is invoked as one expects.

Very interesting.  It sounds like Xenomai is doing cleanup I was
trying to do by hand.  Maybe that is why I crapped the kernel, I am
cleaning up stuff that doesn't exist anymore.  Should I deallocate my
RT fifos?


Thanks,

-kb

Re: [Xenomai-help] Signals

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

Kent Borg wrote:
> On Wed, Jan 25, 2006 at 09:20:28PM +0100, Jan Kiszka wrote:
>>> rt_task_catch() and rt_task_notify()?
>> Those function are - in contrast to what to doc states - not yet
>> available in userspace.
> 
> No wonder information on them is so sparse.
> 
>> So far Xenomai is lacking the infrastructure to
>> deliver hard-RT signals to userspace threads, only the Linux signals are
>> passed as usual.
> 
> But they are passed, that is good.
> 
>> Signals in multithreaded applications are tricky in general, even
>> without Xenomai. You may try to play with pthread_kill and
>> pthread_sigmask to control which thread receives a specific signal.
> 
> I have a very simple architecture, one thread is launched by regular
> means, is launches the RT thread.  It is the parent thread that
> registers for the signal and (I think!) it is the one that gets the
> interrupt.

Try printing pthread_self in your signal handler to be sure.

> 
>> When the signal receiver is a Xenomai thread, the usual things happen:
>> blocking on RT-resources is cleared, the thread is migrated to secondary
>> mode, and the signal handler is invoked as one expects.
> 
> Very interesting.  It sounds like Xenomai is doing cleanup I was
> trying to do by hand.  Maybe that is why I crapped the kernel, I am
> cleaning up stuff that doesn't exist anymore.  Should I deallocate my
> RT fifos?
> 

No, the native skin does not perform much automatic cleanup, especially
not for userspace objects. If I'm not overseeing some detail, the only
thing that gets cleaned up automatically on process termination are
tasks. Even on unloading the native skin module (when being a module at
all anymore), no forgotten userspace object gets deleted. The posix skin
does such cleanup, but only globally, on module unload.

So the rule is the cleanup everything as long as you are able to (i.e.
your application didn't die due to some bug etc.)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]