Open dcristoloveanu opened 3 years ago
Hi @dcristoloveanu we understand the issue you reported. I think this is a defect or unwise design that blob_client
is not thread-safe. As a mitigation, I suggest you make a copy of blob_client
for each async operation.
Hi @Jinming-Hu, yes, this is what we do today as a workaround. Do you see an easy fix for this issue so that we can get a clean solution where we can reuse the same blob_client?
It looks to me that the solution would be to add a RW lock over the properties class.
Thanks, /Dan
Nah, I don't think this would be good. In my opinion, to modify the client itself in an async operation is bad-design. Adding mutex is just going further in the wrong path. I'd rather leave it undefined behavior instead.
Hi @Jinming-Hu
But, but, but, I think undefined behavior without being documented is evil for the developers :-). Why? Luckily we found this in a test and not in production, but it took us some couple of days to identify which is the test out of the test suite that is crashing since call stacks were not always pointing in the right direction as this is a memory corruption.
Now we know about it and we won't pursue using the multiple async calls on the cloud_blob_client in parallel, but I think a line in the function class description XML doc could save a lot of headaches!
If you agree, let me know if you want me to submit a quick PR updating the XML doc for that class.
Thanks, /Dan LE: I understand the argument about this not being designed to support this and you probably do not want to invest in significant design changes on this SDK as the vNext is already available.
Yeah, I agree that adding some docs here will be very helpful to users and save them from a lot of trouble.
If it's too hard to make the code thread safe, can it be make to throw an error if used in a non-thread safe manner? (Like WPF does if you try to modify a UI component from a thread other than the one it was created on.)
If it's too hard to make the code thread safe, can it be make to throw an error if used in a non-thread safe manner? (Like WPF does if you try to modify a UI component from a thread other than the one it was created on.)
It's not possible. The user may maintain a mutex himself and lock the mutex when accessing the client from more than one threads. Storage SDK doesn't even know the existence of that mutex, thus cannot know if the client is being accessed in a thread-safe way or non-thread-safe way.
Hi!
While using the Azure Storage SDK for C++ in our microservice in the Azure Messaging team, we noticed that the the update of properties done as a result of parsing the response for download_single_range_to_stream_async is not thread safe.
This results in crashes if multiple calls to download_single_range_to_stream_async are made for the same blob. Callstack is below.
I guess the updating and accessing properties should be behind a RW lock in order for this to work. A fix in the SDK would be awesome of course. Until then is there a workaround that we could have while still being able to have multiple parallel calls to download_single_range_to_stream_async on the same blob?
I can also provide a user mode dump of the crash. Let me know if you need more details on how to repro the problem.
Thanks, /Dan