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. -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ 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
