thread safety

[jobol]

The current implementation of buxton (libbuxton) is not thread safe and also not safe against notification events.

Trying to run libbuxton in a multi-threaded environment is not possible.

Also, when using true for waiting response in verbs of libbuxton, the implementation doesn't check that the response is the response. Then a notification can take place of the response in an unexpected way.

[bryteise]

For threading I am guessing you are looking to handle one message per thread but I could use a little more details here.

Currently the only shared state should be the callback hashmaps and the message id tracker.

As for using sync in the API, it is not intended to work with non sync. Basically clients should use one or the other though we don't enforce this on connect because I smart client could run a few sync commands and once they are complete switch to async for example. This could be better documented.

[jobol]

First of all, the server is thread safe by design because it runs only one single thread. The issue is only on the client side.

Second, if the client is not multi-threaded or if only one thread use buxton's client API, the client will not reach issues.

Third, if the client is aware of how buxton is working and implements a correct sequentialisation of some critical parts of Buxton, the client will not reach issues. But to get this good working, the programmer has to limit the count of parallel queries to one.

But if a multi-threaded client try to use buxton without care, there are big chances that it will not work properly.

The situation is that if 2 threads emit queries using the synchrounous flag, one or two of the below issues may occur:

• one thread get the answer of the other
• the two threads read partial answer, one getting the begin of the message but not the end that the other one started to have.

The second of the above issue comes from the fact that 2 threads wait using 'poll' on the same file descriptor.

At the opposite, the first is more structural: when waiting an answer, internal code of buxton expects answers to be in sequential order. So it doesn't expect to have 2 (or more) client threads and is not using sequence numbers to fit the answers to the queries.