On Mar 3 2014 3:21 PM, John Kasunich wrote: > On Mon, Mar 3, 2014, at 05:12 PM, EBo wrote: >> >> Euuu... is there any log or indication that a non zero even >> occurred? >> EAGAIN is a drop dead error. That implies, if I understand the >> conversation correctly, that you ran out of memory on the machine. >> That >> should be a fatal error on this type of app. It would be >> interesting to >> discuss how we could do a controlled slow stop if the machine is in >> motion, instead of an emergency stop, but I see this as an emergency >> stop situation. > > I don't think the issue is "what to do if the error occurs". The > issue is > "how do you design it so the error CANNOT occur". The ringbuffer > code is not doing malloc or other dynamic allocation, and it isn't a > question of running out of memory on the machine. I think it > actually > isn't hard to make sure the error won't occur. My gripe is that if > you've > gone to the trouble of making sure the error can't occur, then why > waste CPU cycles testing for it. > > Certainly the error can't occur in the existing code, because the > entire > ringbuffer isn't there. It simply communicates using a couple of > shared > variables, and the code is designed to work correctly.
Fair enough. I am just not so sure that the code can be written to ensure that it cannot occur. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
