Asynchronous stream API is not asynchronous

[Matthias Vogelgesang]

Calls to pcilib_stream block and do not allow an asynchronous operation without introducing a new (user level) thread. As I have to provide a callback method to pcilib_stream, I would assume the call itself is asynchronous and return.

AFAIR, this behaviour is a regression and worked in an earlier version of pcilib.

[Suren A. Chilingaryan]

It is just stream API, not the asynchronous stream API. I.e. it is expected behaviour. I don't like to start threads in the libraries unless there is no ways around. If you want it asynchronous it is only a few operators to start a thread. But you will have a complete control on this thread: priority, affinity, thread pooling. If I'd start thread in the library, you will not able to affect this parameters or I'd need to provide complex interfaces to control them.
Besides, for speed reasons we will use rawdata callback anyway (see ticket #90), which is asynchronous by the way (In this case I don't see a good solution to avoid it at the moment). So, it doesn't really matter.

[Matthias Vogelgesang]

Then why do I have to provide a callback? This makes absolutely no sense in our layered architecture if you block anyway. Just to cite Wikipedia (with deferred they mean asynchronous):

Deferred callbacks are often used in the context of I/O operations or event handling.

This is the case here. So my suggestion: either don't provide a function that takes a callback or make it asynchronous.

[Suren A. Chilingaryan]

I think I have explained why I prefer not to start threads. I'm using this function in pci tool. In my opinion it is more convenient compared to get_next_event approach. So, I'll not remove it. But you are not enforced to use this function if you don't like.