[wireties]

Originally Posted by Greg McKaskle

If the auto thread is politely behaved and checking a cancel or other notification, what is the benefit in forking a thread and killing it. It seems to me that the big benefit of killing the thread is to handle code that is spin-locked, yielded, looping to home in on a target, or otherwise not well-behaved.

Statistically, killing the thread will usually work, but if the thread has acquired a mutex, allocated I/O or other other OS resources, how is a chaperone to know what to delete, what to leave open, what to unlock. Plus depending on the implementation, the lock and other items may have thread-local storage, which means the info has been torn down and the chaperone doesn't have the ability to clean up. If enough shadowing is done with WPILib, those resources can be made safe for killing. OS resources would still be an issue, but should be sufficiently rare I'd think.

Greg McKaskle

VxWorks will release mutex semaphores when a task dies if that flag is set when the semaphore is created. But in general, VxWorks does no cleanup (freeing memory, closing files, etc) when a task dies.

Hope this helps