On Mar 3 2014 1:12 PM, John Kasunich wrote: > On Sun, Mar 2, 2014, at 02:29 PM, Michael Haberler wrote: >> The required operations are: >> >> record_write_begin() - allocate space for a message in the rb but do >> not commit the write yet >> record_write_end() - commit the write operation >> record_next_size() - check data available and operate on same >> record_shift() - consume the record. > > I didn't spend a lot of time studying that code. But a few things > made me cringe. > >>From the code: > > /* record_write_begin(): > * begin a zero-copy write operation for at least sz bytes. This > povides a buffer > * to write to within free ringbuffer space. > * return 0 if there is sufficient space for the requested size > * return EAGAIN if there is currently insufficient space > * return ERANGE if the write size exceeds the ringbuffer size. > > So, tell me what update_freq() should do if the function returns > anything other than zero? It seems to me that you MUST be > absolutely sure that it will always return zero. And if you are > sure (because you allocated the appropriate size buffer, etc,), > then the tests are simply wasting time - after all, you made > sure they would never fail. > > I have no doubt that Pavel's ringbuffer code is well thought > out and serves the general purpose atomic transfer problem > well. But it is overkill (and bloated) if the system has been > properly designed to ensure that you never have allocation > problems. If you do have allocation problems, then you are > screwed in a real-time control application.
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. The ERANGE is a more interesting situation. I agree with John on this one. It should be a critical error as well, but I can see a case where it would be (ummm dare I say acceptable) where the message size is to big, and it is simply telling me to retry/ send the rest a little later. That is acceptable if you can guarantee that there is no missed deadlines. The latter might be a valid situation, where the former is a critical error. The problem I see with putting the e-stop in the ring buffer code, is the idea that errors should be handled where they were initiated, but flagged to warn the caller that something went wrong. That will end you up with something similar to what you have now, and what is worse, if the e-stop control is not accessible at that low a level, then you end up having the same issue as you do now -- where you have to recover from the system error way up the software stack... I could be completely wrong on this, but I see where John is going with it... EBo -- ------------------------------------------------------------------------------ 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
