From: Andreas Leitgeb on 8 Oct 2009 10:58 Mark <i(a)dontgetlotsofspamanymore.invalid> wrote: >>You really need to read out the stuff, or you won't be able to >>tell old received data from new received data. > It is the reponsibility of the consumer of the API to use it > correctly. This is how the whole thing was designed (not by me, I > must add). Was the not-buffering also an explicit part of your outset? If yes, then congrats! They think you're able to do a mission impossible :-) If no, then just do it with buffering... You could also buffer them in persistent memory (e.g. a memory-mapped file), so if your app really crashes, then the newly started one can see the buffered messages left behind by the previous one.
From: EJP on 8 Oct 2009 18:52 Mark wrote: > I use a ByteBuffer for the read, but this question was about detecting > data available, not reading it. .... to which I gave the answer OP_READ. But your original question was about 'non-destructive reads', to which the answer is resetting the position of the ByteBuffer you are reading from. You seem to be constantly redefining the problem so that none of the offered solutions works.
From: Mark on 9 Oct 2009 03:55 On 08 Oct 2009 14:58:59 GMT, Andreas Leitgeb <avl(a)gamma.logic.tuwien.ac.at> wrote: >Mark <i(a)dontgetlotsofspamanymore.invalid> wrote: >>>You really need to read out the stuff, or you won't be able to >>>tell old received data from new received data. >> It is the reponsibility of the consumer of the API to use it >> correctly. This is how the whole thing was designed (not by me, I >> must add). > >Was the not-buffering also an explicit part of your outset? This was a "semi" port from another language. The original code did no buffering. However there was no requirement to avoid buffering. >If yes, then congrats! They think you're able to do a mission >impossible :-) The impossible I do at once. Miracles take slightly longer ;-) -- (\__/) M. (='.'=) Due to the amount of spam posted via googlegroups and (")_(") their inaction to the problem. I am blocking most articles posted from there. If you wish your postings to be seen by everyone you will need use a different method of posting. [Reply-to address valid until it is spammed.]
From: Peter Duniho on 9 Oct 2009 12:44 On Fri, 09 Oct 2009 00:55:20 -0700, Mark <i(a)dontgetlotsofspamanymore.invalid> wrote: >> Was the not-buffering also an explicit part of your outset? > > This was a "semi" port from another language. The original code did > no buffering. However there was no requirement to avoid buffering. From your original post: "I realize I could buffer the messages internally, but I would prefer to avoid this if possible owning to the risk of losing a message if the application is terminated." And look at the topic of this thread: "Non destructive read of socket". How is that not a specific statement to avoid buffering? By definition, if your code buffers the data being read, it's not using a "non destructive read of [the] socket". Now, granted...the reason you gave for avoiding buffering ("risk of losing a message") made no sense. And you never did respond to questions asking you why you thought it did make sense. But "avoid buffering" _was_ part of the original requirements stated in your original post. It's the only reason that this message topic has so many messages in it in the first place; most of the replies have had to deal not only with the specific answer, but also with assessing whether your stated requirement to avoid buffering was in fact necessary and reasonable. Pete
From: Andreas Leitgeb on 9 Oct 2009 17:07
Peter Duniho <NpOeStPeAdM(a)nnowslpianmk.com> wrote: >>> Was the not-buffering also an explicit part of your outset? >> This was a "semi" port from another language. The original code did >> no buffering. However there was no requirement to avoid buffering. > From your original post: "I realize I could ..., but I would prefer to > avoid this if possible ..." > How is that not a specific statement to avoid buffering? No doubt that was an explicit statement in his original post, but my question was not about his original post, but about the job that was assigned to him. As it seems it wasn't an explicit requirement *there*. |