Re: [Xenomai-help] Signals

[Jan Kiszka <jan.kiszka@domain.hid>]

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