this patch has resolved the hang problem when aborting a tool prepare or tool load
I tried to be 'minimally invasive' to force-queue the abort to iocontrol only when the previous message was a tool prepare or tool load. the more I think about it (and tried to abort another blocking operation needed for iocontrol-v2), I think aborts should always be force-queued regardless of the previous command. The reasons are twofold: first, an EMC-side abort is really an out-of-band notification in nature and should always travel first-class, not cattle-class. Second, the current patch introduces a dependency - abort handling is privileged for tool-prepare and tool-load, but not for others, which means newly added messages might again be exposed to the behaviour already fixed for prepare and load until explicitely added to emctaskmain.cc (which I had to do). I've been running emc with unconditional force-queueing of aborts to iocontrol and see no negative consequences so far. Unless somebody comes up with a good reason why not to do this, I'd like to generalize this as above and provide a patch to do so (which is actually a simplification). -Michael http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=5ebf364ad2bc051d04c779bb635ebc89ab4ed09b ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
