Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Linux (e.g. via xnpod_suspend_thread(<cpu-hog>). Unfortunately, there is
>>>> no way to force a shadow thread into secondary mode to handle pending
>>>> Linux signals unless that thread issues a syscall once in a while. And
>>>> that raises the question if we shouldn't improve this as well while we
>>>> are on it.
>>>> Granted, non-broken Xenomai user space threads always issue frequent
>>>> syscalls, otherwise the system would starve (and the watchdog would come
>>>> around). On the other hand, delaying signals till syscall prologues is
>>>> different from plain Linux behaviour...
>>>> Comments, ideas?
>>> We discussed the issue of having a way to force threads to relax with
>>> Philippe, and we both had patches to make this work. However, the issue
>>> we recently had with the emulated iret on x86 makes me think that we can
>>> not relax at any point in time, the code surrounding the relax has to be
>>> made to allow a relax to occur.
>> Those issues were fixed. If we have similar problems around
>> __ipipe_handle_irq (I would expect the relaxation to take place in
>> xnintr_*_handler), then they should be fixed as well.
>> The problem is that I currently do not see any other way of cleanly
>> terminating or debugging some Xenomai user space thread doing "while
>> (1);" (or any more complicated variation).
> I am not really opposed to the "force relax upon signal", thing, but the
> current approach used to work, at least with v2.3.x, so it must be my
> recent rework of thread termination which broke things, maybe we can
> repair them?

That was my first impression as well, but I've some feeling that it was
only silently broken so far. IIRC, Xenomai shadow threads must not run
in unmapped state after deleting their nucleus counterpart (but that's
what we do when the watchdog fired!). Rather, proper termination for
shadow threads goes via relaxing and then do_exit.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to