qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: node.js api poc
Date Thu, 09 Apr 2015 16:33:16 GMT
On 04/09/2015 01:03 PM, Rafael Schloming wrote:
> On Thu, Apr 9, 2015 at 5:53 AM, Gordon Sim <gsim@redhat.com> wrote:
>> On 04/09/2015 05:02 AM, Rafael Schloming wrote:
>>> Can you explain a bit more about the issues you ran into wrapping the C
>>> reactor?
>> When using the c reactors own event loop, you have blocking calls. A
>> handler can be installed that integrates with some other event loop - e.g.
>> the tornado example or the python io handler - in response to reactor
>> events.
> The reactor's event loop is constructed in such a way that you can avoid
> that blocking if you want. The reactor itself doesn't actually block,
> however the C I/O handler blocks when it detects that there are no more
> events to process. This allows pn_reactor_process() to be run in an
> infinite loop without busy looping. If you're doing your own I/O and you
> ignore pn_reactor_run, then the reactor is fully non-blocking.
> Once the C I/O handler is removed then pn_reactor_process() has exactly
> these semantics: It will process events until either a) there are no more
> events to process, or b) one of the event handlers invokes
> pn_reactor_yield. You can also use pn_reactor_quiesced to detect whether
> there are more events awaiting processing.

Ok, thanks for the clarification.

>> However, there is no way that I can see to interact with node's built in
>> event loop from javascript.
> I believe this is typically done by using process.nextTick to post a
> callback to the event loop.

Again, that is a useful pointer, thanks!

>> I'm building a system that needs to communicate between python and
>>> javascript, so I'm glad to see more work on the javascript bindings, but I
>>> will need to be able to use the same C handlers from both python and
>>> javascript, in particular handlers that create new connections. Does that
>>> still work with what you've done, or is there a way to get that to work?
>> No it wouldn't work with what I have done so far. Such handlers presumably
>> use the reactor API, which doesn't exist in what I have done. The reactor
>> would need to be compile by emscripten into javascript in a form that could
>> be integrated with node.
> This is a fairly important use case for me. I also believe it is
> architecturally quite important for future proton development so I'm eager
> to ensure that it works well, or at least avoid anything that will cause
> breaking changes when enabling this sort of thing in the future.

My focus is really on the examples and ensuring simple things remain 
simple. The internal implementation was chosen as the simplest way I 
could see to get things working.

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

View raw message