On Wed, 2015-01-14 at 08:28 -0500, 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.

The goals are spot on, C API looks good at first glance, I'll try to
give it more careful scrutiny. The C handler functions need a void
*context so we can parameterize the callbacks. e.g.

void task_dispatch(pn_handler_t *handler, pn_event_t *event, void *context) {
    ...
    pn_reactor_schedule(reactor, (int)context, handler);
}
...
      pn_handler_t *handler = pn_handler(task_dispatch, (void*)1000);

I'm not sure if you intended a 1-1 relationship between handlers and
callback functions. If you do then you could put the context on the
handler rather than as a parameter to the callback - but that would
force the 1-1 relationship in the implementation from the API.

> 
> 
> 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.
> 
> 
> --Rafael
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org


Reply via email to