Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote: > tru64/alpha gets a core dump at roughly every tenth run of threads6_pasm.
> I suspect some sort of race condition / lack of locking/synchronization > since if I add a short sleep to the main thread, I get no core dumps > after a few hundred test runs. Yep. The main thread could end before the detached. I've added a synchronization now ... > In general the sign of using sleep in multithreaded tests is suspect: > it indicates some sort of expectation of thread scheduling order. ... because, you say it, that's not the way to go. OTOH, I don't know, if user ocde is responsible for waiting on detached threads or if that should be done by Parrot. Currently threads are joined during destruction of the main interpreter but detached threads aren't considered. > P.S. What are "thread1", "thread2", and "thread3"? parrotthread.c > documents them as "threads of type 1..3", but never explains what those > are. These types correspond to terms in Dan's thread proposals. The thread types should finally correspond to different levels of sharedness. C<thread1> e.g. is a "nothing shared at all" thread. leo
