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 ...
In reply to Re^4: Mixing asynchronous data feed with synchronous program flow control
by jcb
in thread Mixing asynchronous data feed with synchronous program flow control
by Your Mother
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |