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.
Xenomai-core mailing list