On Mar 3 2014 3:32 PM, Michael Haberler wrote: > Am 03.03.2014 um 23:12 schrieb EBo <e...@sandien.com>: > >> 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
Sorry I was not a bit more careful in my post. I understand the difference between blocking and non-blocking calls, and what you need to do if a call can only be partially fulfilled because you ran out of buffer -- the ones I have had to deal with typically resend the remaining part of the message to complete. >> 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 It was not intended as a hijack, but following on John's comment. I apologies that we took the conversation down a road you do not appreciate. ------------------------------------------------------------------------------ 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
