Closed thumphries closed 9 years ago
Curiously, I'm getting precisely the same behaviour from the non-threaded runtime.
The only difference is in the client that's left dangling - now it fills up my log dir, whereas before it fell silent after a time.
Updated the gist after getting suspicious that xsRead
and xsWrite
operations were failing to complete.
Looks like that is the case! XenStore transactions are to blame.
Using the threaded runtime, threads occasionally fail to wake up fromEdit: Using either runtime, threads occasionally fail to return from XenStore transactions.threadDelay
.The example is similar to that of #39, which is just ClientRendezvous with 15 clients. A small change to the rendezvous protocol to make it robust to #39 exposes the weirdness. Look for calls to the busy-wait
waitForKey
inRendezvous.hs
(basically defined asxsRead >> threadDelay
). Seems like certain threads are starved indefinitely,and only under contention.Reproduce by running the example until clients fail to halt, and then checking the console for both Server and the dangling Client.
For example, dom593 is left dangling, and the Server log /
xenstore-ls
show the connection was initiated correctly:The Server's console shows it waited for dom593's grants for one iteration, then served a few other clients, and never woke up from that
threadDelay
:Over at dom593's console, it spins for a while, then falls silent. It gave up after 402 attempts, although the domain was still running.
Thread never wakes up on the server. Issue has also shown up on the client side. This example uses the threaded runtime for both server and client. I'm running FC20 and Xen 4.3.3.