In a program using a single event loop, that cannot happen — timers only produce a delay until some time, but do not interrupt other event handlers and timer events are not processed until other callbacks return. There are no races provided that all callbacks return all resources to "safe states" before returning.

Ummm what? Sorry, but no. Take the code exactly as posted in the root node, but in the server code, insert a "sleep 5;" as the first line in on_connect to simulate bad network delay, and then the client will, on many runs, throw the error "Mojo::Reactor::EV: Timer failed: Can't call method "send" on an undefined value", because $TX is still undef at that point. That demonstrates exactly the issue that I was talking about. The code I posted doesn't suffer from that particular issue, because it doesn't start the timer until the connection object is actually available.

Update: I admit my wording "there are a couple of chances for race conditions" may have been a stretch, I initially thought I saw more than the one I described above, but I'm not so sure anymore. However, your claim "that cannot happen" is still incorrect.

I admit my precondition was incomplete as well. The actual requirement is that, upon entering or returning to the event loop, all resources must be in some usable idle state. I still maintain that race conditions cannot occur in a program with a single event loop because the program is implicitly serialized on the event loop itself. The error that you cite is "use of uninitialized value" and the bug is obscured by an asynchronous environment, but it is not a result of undefined timing. It is very well defined: an attempt is made to use $TX some time later, even if the I/O required to initialize $TX is still pending.

I am most familiar with writing Tk callbacks where getting back to the event loop quickly is very important, but Tk ensures that all initialization is complete before the first user callback runs. The error you have found occurs when the event loop is started but some resource used in a callback has not yet been fully initialized. If initializing a connection requires the event loop to run, things get more interesting and you must track the "initialization pending" state somewhere and either drop or requeue timer events until the connection is ready. So the "idle state" for the connection includes a "connected" flag that must remain clear until the connection is actually established.

... and so the pristine model starts to get hairy when put into practice ...

I still maintain that race conditions cannot occur in a program with a single event loop because the program is implicitly serialized on the event loop itself.

I agree that of course one event handler cannot interrupt another. However, I'm not sure what definition of "race condition" you're using here, in my book this is indeed a race condition, see e.g. Race condition - the definition is broad enough that it certainly applies here. (I'd even argue that event loops are a form of cooperative multitasking, so even the "shared resource accessed from more than one thread" definition applies.) But even if the quibble is about the terminology used, the bug still exists.

... it is not a result of undefined timing. It is very well defined: an attempt is made to use $TX some time later, even if the I/O required to initialize $TX is still pending.

Sorry, I don't understand what you mean by "undefined timing" compared to the sentence following it. (Replace the sleep 5; with sleep rand 10; and the bug still exists.)

I am most familiar with writing Tk callbacks where getting back to the event loop quickly is very important, but Tk ensures that all initialization is complete before the first user callback runs. The error you have found occurs when the event loop is started but some resource used in a callback has not yet been fully initialized.

I have to nitpick here that the error is independent of whether the event loop is running or not* - the error is that the timer is started too soon (or that it fires too soon, however you want to look at it). The model you describe of "set everything up before the event loop starts" doesn't work in network servers for example; resources like client connections, timers associated with those connections, etc. come and go, and in most cases can't be initialized before the event loop starts, and instead have to be dynamically allocated and deallocated.

* Update: To clarify: of course nothing can happen if the event loop isn't running; the rest of the paragraph above hopefully makes clear what I meant to say.

If initializing a connection requires the event loop to run, things get more interesting and you must track the "initialization pending" state somewhere and either drop or requeue timer events until the connection is ready. So the "idle state" for the connection includes a "connected" flag that must remain clear until the connection is actually established. ... and so the pristine model starts to get hairy when put into practice ...

That's one possible solution, but I guess I would also describe it as "hairy". Again, I already showed another that solves the issue, IMO cleanly.