On 08/14, Roland McGrath wrote: > > > - minor, but it is possible that tracehook_notify_jctl() will > > be called before tracehook_get_signal(). Not a real problem, > > but shouldn't UTRACE_STOP mean "stop as soon as possible" ? > > No. It means "stop before this thread can newly cause any userland-visible > effects". That means before: > > * executing a syscall (i.e. after report_syscall_entry) > * dequeuing a signal > * returning to user mode
OK, > > - utrace_get_signal() can return without finish_resume_report() > > if B->report_signal() (say) returns UTRACE_SIGNAL_DELIVER. > > > > Yes, in this case A->report_signal() can return UTRACE_STOP > > again, this means utrace_get_signal() returns with ->report = T. > > That's how it's supposed to be. Everybody gets another look after the > thread's state was changed by handler setup. > > > But another UTRACE_INTERRUPT can set ->interrupt, this can > > "disable" ->report again, and so on. > > I don't follow. utrace_resume is guaranteed to be called. Well, utrace_resume() will be called, yes. But it does nothing when ->interrupt == T. But this doesn't matter. Your clarification above answers my question. Oleg.
