Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > >
> > > -ENOPARSE here. Which code is expected to call xeno_mlock_alert_end()?
> >
> > pthread_set_mode_np and rt_task_set_mode. Sorry.
>
> The issue I see doing so, is that you are going to trigger a SIGXCPU
> right after setting the XNTRAPSW bit for the current thread, as a result
> of calling sigaction and friends. This is why I used a plain and dumb
> memory flag instead, the logic being:
>
> - first, trap SIGXCPU in the library ctor to detect the lack of process
> memory locking when mapping a shadow thread, and emit an explanatory
> message when caught.
>
> - as soon as a thread succeeds in setting modes (set_mode_np and
> friends), then we know that a previous shadow mapping for the current
> Linux task has succeeded, otherwise the nucleus would not have been able
> to carry out the set_mode request. In such a case, make sure to cause
> our internal SIGXCPU handler to switch to the default behaviour, in case
> we did set the WARNSW bit for the current thread successfully. In all
> other cases, either the user has set its own SIGXCPU handler overriding
> our internal one, and we have no part in the play, or she did not and we
> won't spuriously emit the "missing mlock" message.
Ok. Another try.
Looks good. Merged, thanks.
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
