On 09/12/13 14:36, Rafael Schloming wrote:
The -7 error code means PN_TIMEOUT, i.e. there was no work that could be
performed within the time limit you passed in, in this case 0. I'm a little
puzzled why you are calling pn_messenger_work twice. The way you have your
code structured the first and second call will happen right after each
other with the first call blocking indefinitely, and the second call
returning immediately. It seems like the second call will serve no purpose
but to return a potentially confusing error code.
Oh, I agree :-)
I guess my explanation of what I was doing wasn't clear. The *only*
reason that I have the pn_messenger_work(messenger, -1); in the main
loop is because that was the only way that I could get things to block
until I had socket activity. To be clear it was really just an experiment.
In my original mail I mentioned that I had actually tried to do
pn_driver_wait(messenger->driver, -1); // Block indefinitely until there
has been socket activity.
But that doesn't even compile (error: dereferencing pointer to
incomplete type). I guess pn_messenger_t isn't externally visible
outside messenger.c so I can't access the driver instance? Which is when
I tried pn_messenger_work as a bit of a hacky "look see" experiment.
So what I'd like to do really is to block until there's some socket
activity, then call my callback - and it's the callback that does the
non-blocking
int err = pn_messenger_work(messenger, 0); // Sends any outstanding messages
So yeah I'm not surprised that you were puzzled, but I hope you see what
I'm trying to achieve now?
I think that your explanation around the -7 probably accounts for why
I'm not reaching the final exit state, so if I can figure out how to
block until socket activity without having to use pn_messenger_work to
do the blocking hopefully I'll be sorted.
You're correct that main_loop might get called a few extra times, but I
doubt it is much of a performance concern. In any performance related
scenario the bulk of what main_loop is going to be doing is
sending/receiving messages, and in this case, 99.99% of socket activity
will be related to exactly that, so even though it may occasionally get
called due to socket activity related to hand shaking or heart beating or
something like that, the odds of there not also being message related work
to process become vanishingly small the more messages you're
sending/receiving.
Seems fair enough, I guess a few extra system calls are *probably* not
going to be the critical path of a non-trivial messaging system, might
get more interesting if we try to push the bounds with large numbers of
small messages.
The asynchronous APIs have been used, but only in one or two cases, so you
are definitely exploring uncharted territory here. FWIW, I agree completely
that the asynchronous case is going to be key in the future.
That's cool, I'm quite happy playing in uncharted waters, though I'm
extremely glad to be getting useful advice :-)
I'm really pleased that I'm not the only one musing over the rise of
asynchrony in a multi-core world, so I really appreciate your comment
there too!!
I think you're close, but I'm not sure exactly what you're trying to do. I
don't see where your code is actually sending outgoing messages or
processing incoming ones. One thing I would say is that you probably only
need to call pn_messenger_work in one place, i.e. where you need to block.
Hopefully my explanation above makes sense? All I'm really doing is a
simple async. rewrite of send.c the message send happens before the
"notifier" loop in this simple case:
.......
pn_messenger_put(messenger, message);
check(messenger);
pn_messenger_send(messenger, 0);
state = SENT_MESSAGE;
check(messenger);
while (1) {
........
And as I say the pn_messenger_work I've got in the main loop is only
'cause it's the only way I could figure how to get it to block waiting
on a file descriptor. I could use a "vanilla" poll, but I'd need to
figure out the descriptors to check so that would get awfully
convoluted. Ideally (I think) being able to access the driver instance
to do pn_driver_wait(messenger->driver, -1); would be the right thing,
but as I say I couldn't get that to compile :-(
I think we could definitely use a set of asynchronous examples to help get
people started here. If you can describe a bit more about what you're
trying to set up I'll see if I can take a crack at sketching out some
example code.
That'd be cool, as I say at this stage I am simply trying to get an
asynchronous version of send.c and recv.c working using a sort of
"notifier" paradigm, I'm sure that I'll have more complex scenario
when/if I ever get the simple one working.
Many thanks for the response Rafael,
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
