> Curiously, this is a one-way change, not a swap, with two threads ending up > with the same thread-id afterwards. I fail to see a replenishing mechanism > which would prevent the system from evolving to a single-thread-id > constellation over time.
At least in theory, I think I understand how it's supposed to work.. This swap only happens between the listener thread T1 and a worker thread T2, whereby the listener thread takes over the worker thread's thread-id. The listener thread doesn't have a unique thread-id of its own, since it doesn't need one -- it always stays in Rx code. After the swap, the listener thread T1 becomes a worker thread, and worker thread T2 becomes a listener thread. When the new listener thread T2 decides to become a worker thread (via the same thread-ID switch), it will acquire another worker thread's thread-ID, and the other worker thread will become the listener. Now, it seems like there's a bug here somewhere.. Maybe we should solve the problem by giving the listener thread a unique thread-ID of its own, and then we would never need to swap thread-IDs when doing hot-thread switching. > Of course the next step is to change rx.c and SWAP the tno's - but I'm afraid > that this code is actually executed pretty rarely and a swap might just > create a problem that passes unnoticed for a long time. I suspect in the case of a pthread fileserver with hotthread enabled, this code gets executed almost all the time.. -- kolya _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
