On 15/01/15 22:54 +0000, Gordon Sim wrote:
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.
I think the interface looks pretty sane to me. I looked at it a couple of weeks ago and I was planning to take another look and provide a more useful feedback. One thing that I did want to mention (and forgot, obviously) is that for things like non-blocking IO, we want to make sure the API works well not just with eventlet but also with asyncio[0]. Also, it'd be worth taking a look at how the Twisted[1] api works since it's a long-time python project with an event based API like the one you guys are building for proton. Hope this helps, Flavio [0] https://docs.python.org/3/library/asyncio.html [1] https://pypi.python.org/pypi/Twisted -- @flaper87 Flavio Percoco
pgpBoEJtnNEVU.pgp
Description: PGP signature
