qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: c reactor / gordon's examples
Date Thu, 15 Jan 2015 22:54:31 GMT
On 01/14/2015 01:28 PM, Rafael Schloming wrote:
> Hi Everyone,
> I've been doing some work on a C reactor API for proton that is intended
> to fit both alongside and underneath what gordon has been doing in pure
> python. I have several goals with this work.
>   - Simplify/enable a reactive style of programming in C that is similar
> to what gordon has built out in pure python.
>   - Provide a C API that translates well into the python/ruby/etc
> bindings, so that sophisticated handlers can be written once in C rather
> than being duplicated in each scripting language.
>   - Preserve the extensibility/flexibility that comes with being able to
> define custom handlers in the bindings, so python/ruby/etc handlers can
> intermix well with C handlers.
>   - Provide a C API that translates well into javascript via emscripten.
> In some ways this is similar to the above goals with the other language
> bindings, however I mention it separately because there are additional
> memory management constraints for javascript since it has no finalizers.
> I believe I've made significant progress towards most of these goals,
> although there is still plenty of work left to do. I'd like to share a
> few examples both to illustrate where I am with this and to solicit
> feedback and/or help.
> Let me say up front that these examples aren't intended to be "hello
> world" type examples. The focus of this work has really been on the
> reactor/handler/event-dispatch infrastructure, and so the example I've
> chosen is really intended to illustrate key aspects of how this works.
> To do that I've built an example that sets up a recurring task, a
> server, and a client, all within the same process and then sends a
> number of messages to itself.
> I've included the same example twice, once written in C and once written
> in the python binding of the C API. Please have a look and let me know
> what you think.

Attached is that example using the pure python utilities I've been 
working on. It's similar in many ways, but there are some differences.

Ideally we can start to reconcile these differences, particularly for 
the python bindings, both to avoid the confusion of having slightly 
different variants of the same functionality and to allow more flexible 
combining between c and python (e.g. calling c handlers from python, 
using the c event loop with python handlers etc). I think that exercise 
will also be a useful way of solidifying some of the interfaces.

There are a couple of immediate improvements I want to make based on 
your example. The first is having the 'reactor' (I currently call the 
equivalent 'container') as a property of all events. That avoids the 
need to explicitly 'plumb it in' to components. The other is to add a 
handler argument to the schedule call allowing specific timed events to 
be handled by a given piece of logic.

The second point also opens up the wider question of how handler scoping 
works. There are some differences there between our approaches that are 
worth digging into and rationalising.

The first point impacts on a question I've been thinking about which is 
the correct layering (if any). I started to use the term 'container' for 
something that had some higher level utility as an AMQP container, over 
and above the 'event loop'. Figuring out what the layers are, what they 
should be called and what exactly their interfaces are will be worthwhile.

Anyway, more to come on all this from me, but I wanted to chip in 
briefly. I think we are building some momentum around the approach here, 
the c variant is an interesting addition - nice work - and I think also 
an opportunity to start unifying and consolidating things.

View raw message