Hi,
I am not sure I understand your question, but I will try.
libiscsi is not threadsafe by design.
It is fully non-blocking and asynchronous so that you will get maximum
performance also from single-threaded applications.
For multithreaded applications, there are several ways to deal with this.
1, you could dedicate one single thread for all libiscsi I/O.
2, you could protect all the calls to libiscsi with a mutex and thus
make sure that only a single thread at a time calls down into
libiscsi.
All library functions, except iscsi_service, should never block and
should always guarantee to respond in sub-ms. iscsi_service can not
give that guarantee to return since it will call out to callbacks in
your application and is thus bound by your applications callback
behaviour.
IF you can guarantee that your callbacks will always return promptly
and never block
then you could treat iscsi_service() similarly.
Since modern futexes are very fast for the non-contended case it
should not be very expensive. Also since the duration for the libiscsi
calls would always be guaranteed to be very short, I would imagine
that the non-contended case would be the normal case.
If you don't have futexes but have to fall back to traditional mutexes
then it might be quite expensive since the cost for taking and later
releasing the mutex might be quite expensive compared to the cost of
the libiscsi call itself.
3, Create one independent context for each thread. Contexts are cheap.
QEMU I think it falls into the category 1. I think it will not call
down into the block layer, and thus the iscsi layer, from multiple
threads concurrently.
>
> Regards,
> Roy
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "libiscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
libiscsi+u...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.