On Wed, Mar 6, 2013 at 6:52 AM, Ted Ross <[email protected]> wrote: > > On 03/06/2013 08:30 AM, Rafael Schloming wrote: > >> On Wed, Mar 6, 2013 at 5:15 AM, Ted Ross <[email protected]> wrote: >> >> This is exactly right. The API behaves in a surprising way and causes >>> reasonable programmers to write programs that don't work. For the sake of >>> adoption, we should fix this, not merely document it. >>> >> >> This seems like a bit of a leap to me. Have we actually seen anyone >> misusing or abusing the API due to this? Mick didn't come across it till I >> pointed it out and even then he had to construct an experiment where he's >> basically observing the over-the-wire behaviour in order to detect it. >> >> --Rafael >> >> > The following code doesn't work: > > while (True) { > wait_for_and_get_next_event(&**event); > pn_messenger_put(event); > } > > If I add a send after every put, I'm going to limit my maximum message > rate. If I amortize my sends over every N puts, I may have > arbitrarily/infinitely high latency on messages if the source of events > goes quiet. > > I guess I'm questioning the mission of the Messenger API. Which is the > more important design goal: general-purpose ease of use, or strict > single-threaded asynchrony?
I wouldn't say it's a goal to avoid background threads, more of a really nice thing to avoid if we can, and quite possibly a necessary mode of operation in certain environments. I don't think your example code will work though even if there is a background thread. What do you want to happen when things start backing up? Do you want messages to be dropped? Do you want put to start blocking? Do you just want memory to grow indefinitely? --Rafael
