qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Proton's new async features - any examples? 'cause I'm scratching my head!
Date Sat, 15 Mar 2014 09:38:38 GMT
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 <
> fraser.adams@blueyonder.co.uk> 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: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message