Thanks Rafael,
I'll take a look at this.
TBH I had actually done a bit of grepping around and had come across
SelectableMessengerTest, but unfortunately I think that only confused me
more :-/
I guess that my mental model of how I'd expect to use this would be in a
notifier loop analogous to a "broken apart" version of:
while (1) {
pn_messenger_work(messenger, -1); // Block indefinitely until there
has been socket activity.
process();
}
So seeing the non-blocking select and the way Pump was being used in a
"busy wait" loop messed with my head - though I suspect that was just
down to me "over analysing" things :-D
I have to say that I agree with the comments raised by Darryl Pierce
yesterday evening about some of the names being a little confusing.
Out of curiosity how much more efficient would you expect this approach
to be? I'm guessing if you have several messenger instances on the go
and a high message rate it's likely to make quite a difference and you
can also use epoll now too I guess.
FYI when I tried "make docs" it mostly looks like it works but I saw
several warnings:
warning: ignoring unsupported tag `INLINE_SIMPLE_STRUCTS =' at line
313, file user.doxygen
warning: ignoring unsupported tag `CITE_BIB_FILES =' at line
583, file user.doxygen
warning: ignoring unsupported tag `MATHJAX_EXTENSIONS =' at line
1166, file user.doxygen
warning: ignoring unsupported tag `LATEX_BIB_STYLE =' at line
1285, file user.doxygen
warning: ignoring unsupported tag `INTERACTIVE_SVG =' at line
1699, file user.doxygen
and
Scanning dependencies of target docs-py
+--------------------------------------------------------------------------
| In /home/fadams/qpid/qpid-trunk/proton/proton-c/bindings/python/
| proton.py:
| Import failed (but source code parsing was successful).
| Error: NameError: name 'PN_CONNECTION_STATE' is not defined (line
| 3292)
|
It looks like your new API docs are created OK, but I've raised
PROTON-535 to cover it.
Best Regards,
Frase
On 14/03/14 20:01, Rafael Schloming wrote:
I don't have examples yet, other than the SelectableMessengerTest in
messenger.py. I did just commit the doxygen API-docs for all that stuff a
couple of minutes ago, so you might start there. You'll need to do a 'make
docs' from a trunk proton checkout and then point your browser to
<your-build-directory>/proton-c/docs/api/html.
Have a read through of what's there now and let me know what questions you
still have. I'm happy to explain more, but I'd like to get a sense for what
gaps there are left in the docs.
--Rafael
On Fri, Mar 14, 2014 at 11:38 AM, Fraser Adams <
[email protected]> wrote:
Hey folks,
I've noticed that PROTON-525/531/534 cover work to expose some bits of
messenger that were previously internal and allow messenger to be driven
from an external poll/select/epoll.
I'm quite interested in this from the perspective of the JavaScript
bindings that I'm working on, but to be honest I'm currently left
scratching my head trying to figure out how the new APIs are intended to
work.
I don't suppose that there are any examples available?
I currently have a recv-async.c and send-async.c (attached) they are still
a bit hacky as they are currently work in progress as I push the necessary
features into emscripten (the C->JavaScript compiler I'm using) but they
both work in either native C or JavaScript (the emscripten_set_network_callback
gets triggered by WebSocket activity and allows fully async behaviour, so I
don't need any nasty polling).
I've just merged the latest proton-c stuff to the branch I'm working on
for the JavaScript bindings and everything is still working nicely with the
current approach, but I'm guessing that the new capabilities might be able
to make things more efficient?
I'm currently working on actual binding code, so I can call messenger
direct from native JavaScript as opposed to compiling C/C++ into
JavaScript, so far it has got a lot of parallels with the python bindings -
though clearly only async stuff makes any sense for JavaScript.
I'd really appreciate tips and code samples from the folks who have been
working on this API.
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
