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.



Xenomai-core mailing list

Reply via email to