Asynchronous APIs

Question

Hi,

When trying to implement a asynchronous API calls / Non-blocking calls, i know a little in a All Plain-C applicaiton I have, i read a about APM(Asynchronous Programming Model) by 'Delegates'. Basically what i want to do is call one API f1() to do a functionality(which takes long time 8-10 seconds), So i call that API f1(), forget about it, and continue doing some other work, e.g. I/O for to fetch data for next call of the f1() or some functionality not dependant on result of f1().

If any one has used that APM model of programming, I am looking at some concise explanation for implementing non-blocking calls.

Is there any other way of implementing asynchronous APIs , any other library/framework which might help in this?

-AD

Answer 1

Replace delegates with pointers to functions in C, everything else is basically same to what you have read.

Answer 2

You basically need to create a multi-threaded (or multi-process) application. The f1() API needs to spawn a thread (or process) to process the data in a separate execution space. When it completes, the f1() routine needs to signal the main process that the execution is done (signal(), message queues, etc).

Answer 3

A popular way to do asynchronous programming in a plain C programs is to use an "event loop". There are numerous libraries that you could use. I suggest to take a look at glib.

Another alternative is to use multiple pre-emptive threads (one for each concurrent operation) and synchronize them with mutexes and condition variables. However, pre-emptive threading in plain C is something I would avoid, especially if you want to write portable programs. It's hard to know which library functions are re-entrant, signal handling in threaded programs is a hassle, and in general C libraries and system functions have been designed for single-threaded use.

If you're planning to run your application only on one platform (like Windows) and the work done with f1() is a relatively simple thing, then threading can be OK.

Answer 4

If the function f1() which you are referring to is not itself implemented in a asynchronous fashion, you will need to wrap it up in its own thread yourself. When doing this, you need to be careful with regards to side effects that may be caused by that particular function being called. Many libraries are not designed in a thread-safe way and multiple concurrent invocations of functions from such libraries will lead to data corruption. In such cases, you may need to wrap up the functionality in an external worker process. For heavy lifting that you mention (8-10 seconds) that overhead may be acceptable. If you will only use the external non-threadsafe functions in one thread at a time, you may be safe.

The problem with using any form of event-loop is that an external function which isn't aware of your loop will never yield control back to your loop. Thus, you will not get to do anything else.

Answer 5

Well. Basicly I've seen 2 types of async API:

1. Interrupt. You give a call a callback which should be performed after the call. In such way works GIO (part of previously mentioned GLib). It is relativly easy to program with it but you usually have the thread in which the callback will be run changed (except if it is intergrated with main loop as in case of GIO).
2. Poll. You check if the data is avaible. In such manner well-known BSD Sockets operates. It has an advantage of not necessary being integrated with main loop and running callback in specific thread.

If you program for Gnome or Gtk+-based I'd like to add that GTask seems to be a very nice (potentially nice? I haven't used it). Vala will have better support for GIO-like async calls.