wait_for_thread doesn't seem to work.

[mmu_man]

wait_for_thread() doesn't seem to always find death records of dead threads, and gives bad results anyway:

~>thtest err = 00000000 st = 00200aa0 err = 00000000 st = 00200aac ~>thtest err = 80001100 st = 001071ac err = 00000000 st = 00200aac ~>error 0x80001100 0x80001100: Bad thread ID

In Zeta:

$ ./thtest err = 00000000 st = 00000000 err = 00000000 st = 00000000 $ ./thtest err = 00000000 st = 00000000 err = 00000000 st = 00000000

[mmu_man]

wait_for_thread test

[axeld]

The result of the first wait_for_thread() is random even under BeOS - to make it safe you have to remove the resume_thread(). To let it always fail, just add a short delay before wait_for_thread().

I'll look into the wrong return code, though; I guess I recently broke that when fixing arch_thread_enter_userspace(). It does work correctly in the case of the fibo_* tests, BTW.

[mmu_man]

The first one doesn't seem very random to me (yes I tried other values), but maybe it got fixed in Dano.

[axeld]

It's not a bug in BeOS nor Dano - it's a bug in *your* code. As I said, to make it clearer, just add a delay after resume_thread() but before wait_for_thread(). Dano's wait_for_thread() will then fail as well (as it should).

Anyway, the actual bug in Haiku is fixed in hrev20060, thanks for noticing! :)

[mmu_man]

Actually I tried sleep5&) after resume_thread and it didn't fail.

I didn't dig the Haiku code, but BeOS keeps the death reason and return code around until the team dies in a list of struct death_rec (and the parent team inherits the last one... or rather the one from the first thread IIRC. which I think is why sometimes the tty gets mad, because the shell doesn't get the ret code it expected). Now I remember I wanted to extend death_rec to keep the kernel and user times to be able to implement the missing wait3 or wait4, whichever.

[mmu_man]

sleep(1) I meant

[axeld]

I tested with sleep(1) on Dano, and the same thing happens as on Haiku and on R5. If it doesn't happen with Zeta, then it got changed after Dano got "published". Nevertheless, it's not a bug, just a different behaviour. The shell doesn't have anything to do with this, as teams collect the death entries of their children (but not single threads, only teams).

[mmu_man]

I know I did some changes in the thread code in Zeta, but I'm sure I didn't change that. Now currently wait_for_thread searches in the death_recs for the calling thread's team.

And yes it does have to do with teams as well, at least in BeOS since it's handled with the same death_rec list, a diing team leaving its own death_rec (that of it's first thread actually) in testimony to its parent team. The fact that the team's return value is arbitrarily that of its first thread makes me think it has to do with the tty getting messed up, as I suspect the shell might actually want another thread's rec but doesn't get it.