-
Notifications
You must be signed in to change notification settings - Fork 409
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
Thread safety of the library? #435
Comments
Hello @marshallpierce, Those are some great observations! Thanks for taking the time to detail your findings. I've added this issue to our backlog for further investigation. If you like, we welcome and encourage PRs :) With Best Regards, Elmer |
Is this issue still open? I would like to help out. |
Haha over 2 years and this is still open. I am looking for better alternatives then SendGrid! :) |
I just wrote my own client since this library is clearly abandonware |
Hi,, any updates on this? |
Hello @harishajdarevic, No updates just yet, but since you have commented here, we will reopen and add to our internal backlog. Additional comments and +1s will help this issue move up our backlog. Thank you!! With best regards, Elmer |
I see from #213 that the library is claimed to be thread safe. However, a few minute's inspection of the
SendGrid
class shows this is not true. All fields are not safely initialized, and therefore all usage of them is unsafe. Similarly, therequestHeaders
field is itself mutable and not thread safe. I stopped looking once I found that much, so there may well be more elsewhere. However, the class looks like it was intended to be reused, given that it launches a thread pool (which leaks threads -- there's no way to close the thread pool).As a potential user of the library, what should I make of this? Is it intended that
SendGrid
should be thread safe?The text was updated successfully, but these errors were encountered: