Re: Design question: asynchronous API in C++

Discussion in 'C++' started by Adam Skutt, Jan 1, 2011.

  1. Adam Skutt

    Adam Skutt Guest

    On Thursday, December 30, 2010 2:15:44 PM UTC-5, Marcel Müller wrote:
    > I want to provide an asynchronous C++ API. I.e. placing a request will
    > not immediately provide a reply. Instead a callback signals the
    > availability of the result.


    None of the existing libraries that provide this sort of functionality are adequate? ACE, boost.asio, several others? Lots of people have done asynchronous I/O in C++ before, and much better than the way that MS does it in ..NET.

    >
    > The classic solution is to provide an interface that must be implemented
    > by a class of the caller. This interface contains a method for the
    > asynchronous callback.
    >
    > Advantage: the implementing classes could also be used to track the
    > state of the request. (In this case it is an abstract base class rather
    > than an interface.)
    >
    > class AsyncBase
    > {
    > // Notify availability of result.
    > virtual void OnCompleteion() = 0;
    >
    > // Cancel an outstanding request.
    > // Do not call OnCompletion once it returns.
    > void Cancel();
    >
    > // Fetch the result data (and wait if necessary).
    > // If called from OnCompletion() the returned data must not be used
    > // after OnCompletion returned.
    > // If /not/ called from OnCompletion the lifetime of Result is
    > // extended until this class instance dies.
    > const Result& ReceiveResult();
    > };
    >
    > Unfortunately this is very bulky, because the caller has to implement
    > one class for each different call. So I would like to have a more
    > convenient API.
    >


    No, they don't. For example, write an implementation of that interface that takes a function as a parameter and calls that function when the result is available. ACE uses this technique in a few places, as I recall. They only have to keep writing classes if they constantly need different state. Even that can be resolved to a large degree by templates (reducing the problem to the amount of stored state) and so on.

    Or, do the sensible thing and not mandate such a complicated interface just to get an asynchronous result. Look at what boost::asio does, for example.. Fundamentally, a callback is just a function and your API should reflect that. If they need to store state with their function, let the API user create a functor (or use boost::bind, or whatever).

    > I think that Lambda expressions would help. However, my compiler does
    > not support them.


    So use boost::lambda? Yes, they certainly can help, but without details...

    Adam
     
    Adam Skutt, Jan 1, 2011
    #1
    1. Advertising

  2. Adam Skutt wrote:
    > None of the existing libraries that provide this sort of functionality are adequate? ACE, boost.asio, several others?


    The question is more how much work is it to port them to all the target
    platforms. And the second question is how bulky they are.


    >> Unfortunately this is very bulky, because the caller has to implement
    >> one class for each different call. So I would like to have a more
    >> convenient API.
    >>

    >
    > No, they don't. For example, write an implementation of that interface that takes a function as a parameter and calls that function when the result is available. ACE uses this technique in a few places, as I recall.
    > They only have to keep writing classes if they constantly need different state. Even that can be resolved to a large degree by templates (reducing the problem to the amount of stored state) and so on.
    >


    > Or, do the sensible thing and not mandate such a complicated interface just to get an asynchronous result.


    The interface is already there. It is a C API (pulseaudio port to OS/2).
    But it requires a callback function to be passed and returns a request
    object pointer. However these two things are not related directly which
    is very error prone. E.g. one cannot call a wait function on the request
    object pointer, because this object does not receive the callback. On
    the other side the request object is needed to cancel an outstanding
    request and prevent the callback from being called anymore.

    I would like to wrap that by a C++ implementation. This should consist
    of a single request object which deals with the callback as well as the
    request object in a single place. Unfortunately the callback information
    is input from the APIs point of view, while the request object is output.
    In fact a single request has to join an object to query, the request
    itself, and a request handler in one statement of code.


    > Look at what boost::asio does, for example.


    I will do so.

    > Fundamentally, a callback is just a function and your API should reflect that. If they need to store state with their function, let the API user create a functor (or use boost::bind, or whatever).
    >
    >> I think that Lambda expressions would help. However, my compiler does
    >> not support them.

    >
    > So use boost::lambda? Yes, they certainly can help, but without details...


    Hmm, I have to check whether boost:lambda compiles on my platform. I did
    already use other parts of boost, but this one is untested.


    Marcel
     
    Marcel Müller, Jan 1, 2011
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Amir

    asynchronous design

    Amir, Oct 10, 2003, in forum: VHDL
    Replies:
    3
    Views:
    609
  2. dutchgoldtony

    Asynchronous Design

    dutchgoldtony, Apr 23, 2005, in forum: VHDL
    Replies:
    3
    Views:
    496
  3. Marcel Müller
    Replies:
    4
    Views:
    1,049
    Öö Tiib
    Jan 1, 2011
  4. Adam Skutt
    Replies:
    2
    Views:
    729
    Adam Skutt
    Jan 1, 2011
  5. Scott Sauyet

    API for aggregator of asynchronous calls

    Scott Sauyet, Jun 29, 2010, in forum: Javascript
    Replies:
    7
    Views:
    133
    Scott Sauyet
    Jul 1, 2010
Loading...

Share This Page