Am 03.03.2014 um 23:12 schrieb EBo <[email protected]>: > 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.
sorry, that is nonsense - it is a nonblocking operation just as read() with a nonblocking file descriptor if you understand on how thread functions work, you fill find blocking reads make threads drop dead, so here's your drop dead error > That implies, if I understand the > conversation correctly, that you ran out of memory on the machine. no, you did not, read all of the code - ringbuffers are allocation-time fixed size, and the operations do return error codes as required and makes sense in the errno taxonomy moreover this aspect is completely irrelevant to the discussion topic at hand, which is about using scheduling behaviour used to assert certain properties of parallel programs can we focus on the actual problem please, which is _really_ fundamental - which is why I object to thread hijacking -m > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
