Skip to main content
gamedev.net
🔒 Locked

Asynchronous function call library

Started by the_edd 2 replies 900+ views
Original Post
the_edd
the_edd
Hi folks, A few days back I massaged my C++ library for calling functions and functors asynchronously in to what I hope is reasonable shape. If anybody's interested in checking it out, I'd love to get some feedback. Making an asynchronous call returns a 'future' immediately, which may be redeemed later on when the time is right. There are a number of other libraries that do similar things, but they seemed not to have very good support for propagating exceptions and/or passing and returning references. Usage looks something like this:

using std::string;
using std::vector;

// A time-consuming function
string merge_xml_files(const vector<string> &files);


// An object used to catch exceptions, can be reused for
// any number of asynchronous calls
async::layered_cage<std::exception, xml_parse_error, async::catch_all> cage;

vector<string> xml_files;
// fill xml_files
// ...

// call merge_xml_files(xml_files) asynchronously
async::future<string> fut = async::call(cage, merge_xml_files, xml_files);

make_virtual_cup_of_coffee();
// ...

string merged_xml = fut.value();


There are a bunch of other related features which you can read about, if interested: async library. Cheers, Edd
Spoonbender
Spoonbender
Sounds interesting. I'll definitely check it out later today. One quick question though. How are the async calls actually performed? Do you just spin off a thread to call the function?

What if I want to wrap asynchronous OS calls (like Windows' Overlapped I/O, or perhaps just nonblocking sockets), without having to create a thread per call to wait for the result?
Can it be adapted to handle cases like that?
the_edd
the_edd
Quote:
Original post by Spoonbender
Sounds interesting. I'll definitely check it out later today. One quick question though. How are the async calls actually performed? Do you just spin off a thread to call the function?

Currently, yes. I plan on changing things so that existing threads are re-used in a future iteration of the code. You'll find some notes about that on the web-page. But if I've done things right, the interface to the library shouldn't change.

Quote:
What if I want to wrap asynchronous OS calls (like Windows' Overlapped I/O), without having to create a thread per call to wait for the result?
Can it be adapted to handle cases like that?

To be perfectly honest with you, I'm not at all familiar with Windows' overlapped I/O. I'll try to investigate this. If you have any recommended links, beyond those I'd find through google, please let me know!

Edit: async::future<> is implemented in terms of a strategy (as in the design pattern). You could perhaps derive your own strategy for handling overlapped I/O, but again I'll do soem more reading on this, soon.

Thanks,

Edd
Antheus
Antheus
Boost::ASIO does asynchronous execution. It doesn't have futures, but uses proactor or reactor model for dispatching events, and includes transparent synchronization mechanism. Function calls are boost function wrappers, so they tie directly into code.

The services for network IO are provided (IOCP under windows, kqueue or epoll on other platforms).

The reason I dislike futures is because of their blocking nature. In tight code, there's frequently no benefit, and the incurred overhead may actually worsen the execution.

Not a critique of design, merely pointing out an alternative tool.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.