<font face="courier new,monospace">I'm not sure how to adequately describe the problem I'm having but...<br><br>My application interacts with other remote programs via TCP<br>as both a server and a client.<br><br>b) When the app doesn't have an object it creates one,<br>

   does a push_write(),<br>   then returns the blessed object.<br>c) the caller/mainline records that object<br>d) go to step 1<br><br>The pseudo code is:<br><br>sub new {<br>   my $obj = bless {}, $class;<br>   $connection->push_write(...);<br>

   return $obj;<br>}<br><br>sub a_read_handler {<br>  $row = new(...) unless defined $row;<br>  ...<br>}<br><br>The way I can explain my symptoms are that I have a race condition where...<br><br>I call new() alot (to create many objects), which means that push_write()<br>

has been called alot...<br></font><font face="courier new,monospace"><font face="courier new,monospace"><br></font>Calling push_write() eventually defers the returning of the object being<br>created</font><font face="courier new,monospace"><font face="courier new,monospace"> [because the outbound queue is backing up and its trying to empty it]<br>

</font>to the point where my mainline, since it hasn't received the returned<br>object yet, hasn't saved it, and so when it performs its test, and doesn't<br>find it, and calls new() again [for the same 'thing'].<br>

<br></font><font face="courier new,monospace"><font face="courier new,monospace">[Because of the other interactions between my various apps,<br>a 'system messaging corruption' would then occur.</font>]<br><br>Conclusion: It seems like calling push_write() can allow my<br>

            read_handler to run before the new has returned.<br><br>If this is indeed possible...<br>  'is there any way I can force the push_write to be asynchronous,<br>  to ensure the return happens _first_?'<br>

<br>[I've read about 'guard', but I don't know if that's what I<br>should use, or is there something else?]<br><br>TIA<br>Fulko<br><br></font>