On 2011-07-12 13:56, Jan Kiszka wrote: > However, this parallel unsynchronized execution of the gatekeeper and > its target thread leaves an increasingly bad feeling on my side. Did we > really catch all corner cases now? I wouldn't guarantee that yet. > Specifically as I still have an obscure crash of a Xenomai thread on > Linux schedule() on my table. > > What if the target thread woke up due to a signal, continued much > further on a different CPU, blocked in TASK_INTERRUPTIBLE, and then the > gatekeeper continued? I wish we could already eliminate this complexity > and do the migration directly inside schedule()...
BTW, we do we mask out TASK_ATOMICSWITCH when checking the task state in the gatekeeper? What would happen if we included it (state == (TASK_ATOMICSWITCH | TASK_INTERRUPTIBLE))? Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core