On 11/14/2012 12:56 PM, Rafael Schloming wrote:
On Wed, Nov 14, 2012 at 6:37 PM, Ted Ross <tr...@redhat.com> wrote:
On 11/14/2012 11:49 AM, Rafael Schloming wrote:
How does the packaging prevent this?
1) Develop the non-blocking aspects of the API. This might just
involve a
few additions to the current API or possibly adding a distinct
non-blocking
API which would be a layer underneath the current API. Either way, this
non-blocking API then becomes the top half of the messenger engine.
This is good, but I claim that the blocking/non-blocking of the messenger
API is an orthogonal concern. The style of API used is related to the
programming model used in the application. I think that users will want to
have the "native" driver and use the blocking messenger API.
Yes, but unless I'm missing something, the blocking calls will need to be
"native" as well since they will need to call into the native driver to
block, and so they will need to be built on top of a non blocking API.
I'll use a concrete example. Assume we have a python program using the
current messaging API (which has three blocking calls). Assume further
that the driver is written in Python and uses a blocking mechanism
appropriate for the in-use threading library. Since the only place
proton *ever* blocks is in pn_driver_wait, and pn_driver_wait is written
in python, everything works correctly even though the program uses the
"blocking" messenger api.
-Ted
