Is having a function call block a bad design process?

Question

I'm writing an API which is used to receive some data from another application. Currently the function is designed to block until data is received. In my mind this limits developers using the API to use multithreading or some sort of multi-process design. So is it better for a function to block or to return a null and then sleep for a few milliseconds before trying again.

Note the other application may not have any data to send through the API for an unknown period of time.

The API is written in C++

Answer 1

You haven't said what language this is, but it sounds like your API is listening or checking for some event, and the users of the API are either blocking or polling your API to determine if the event happened?

Is it possible to use a callback? Users of the API would register for notifications of the event happening, and when your library detects the event it will use the callback to notify all listeners.

Answer 2

Why not use a callback?

Answer 3

Consider another option: use an async transaction -> issue a request & provide a callback address with ticket id. When the response is available, the service end-point callbacks your application with the ticket id and of your the result ;-)

You should avoid as must as possible blocking when you possibly can.

---

As you say:

Note the other application may not have any data to send through the API for an unknown period of time.

In this case, using a synchronous interface ties up resources unnecessarily.

Answer 4

You could define the API to allow the user to pass an optional timeout value. If the timeout is not specified, then the API function waits indefinitely, much like how select() works.

Answer 5

When your applications calls the O/S api function read(), do you expect it to block? Of course you do—at least by default. In some circumstances, ioctl's allow a programmer to change the behavior to be asynchronous, which is particularly common in network applications.

You've shed very little light on what your API is about, so consider:

• Does it make sense that an API user would want to be blocked? That is, is there little to do until it returns.
• If you were writing an application for the API, what would you expect it to do? You should definitely write a few sample applications for your own education, as well as to document the API.
• Is there any reason why the API user would not multithread (or fork, etc.) requests to the API?

Answer 6

If you want a reusable solution you could apply the Asynchronous Design 'Pattern' which is common in .NET but can also be implemented in C++ as demonstrated in this CodeProject project.

There's nothing wrong with providing both synchronous and asynchronous calls to the same feature in the interface.

Personally I would only go these lengths if I need to service multiple requests (in which case you can queue 'BeginOperation' requests for example), or there are many potentially asynchronous operations in the interface (and I want a standardised, flexible pattern). If you can only handle one request at a time a time-out is usually sufficient.