-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock when calling upload again from the success callback (FileSystemManager) #35
Comments
Hi Tristan, thanks for submitting this issue! After reading the code again myself, I would agree that a deadlock seems unlikely. Did you find the source of the deadlock? Or is deadlock just an educated guess based on symptoms? So, if I understand the timeline correctly:
It's quite interesting that it works if you dispatch the second file upload. I would also be interested in seeing what happens if you initialize a new I can dedicate a bit of time to this next week. In the meantime, if you could step through the second call to upload, even down into the BLE transporter, and identify where we are getting blocked, that would make my life a bit easier :) |
I did more tests today, I tried to upload a file right after downloading a file and always got the error:
Then I noticed that in the
and then
So, if I upload file immediately in the downloadCallback, the transferState will be .uploading and error will be thrown. |
Thanks for looking into it more. The order of those two calls was recently changed in order to avoid a crash. Commit: a4c95e7 PR: #33 At first glance, It looks like we should be copying the |
We're running into a strange issue using the file upload service. We need to upload 2 files, and mapped the success callback into a completion handling closure. We tried uploading the 2nd file from this handler and we get a deadlock and no file is uploaded. We're using a BLE transport.
We've reviewed the code in this library and can't really see a cause for it, and the solution we have is to dispatch the second call on a background queue. However, it seems like this should be supported because:
I can provide examples and references if this isn't sufficient to understand or recreate the situation, but I'm mostly concerned that we're doing something else wrong and this async dispatch is just sweeping things under the carpet.
Any thoughts/help appreciated, thank you. And great work on the library, it looks really solid!
The text was updated successfully, but these errors were encountered: