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

Reply via email to