-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Is Sink.is_writable() thread-safe #1952
Comments
@ochafik thanks for the interesting question. According to the following article, POSIX socket operations like send/recv are atomic.
Lines 5819 to 5822 in 10d68cf
Lines 3104 to 3130 in 10d68cf
Lines 3189 to 3198 in 10d68cf
So it seems like it's ok to call Did you find any actual problem in your project? If so I may be able to try to reproduce it on my machine. |
@yhirose thank you so much for the detailed research and prompt reply! No actual problem but the question was raised by @ngxson in a code review, hoping to avoid running into problems if that PR gets merged :-D |
Hmm in this case, if only taking into account POSIX (linux, bsd), then For llama.cpp, this can have negative impact on inference if there're |
select_read alone didn't seem to cut it but is_socket_alive (= select_read + read_socket) seems to work -> #1956
It looks like winsock should be reasonably threadsafe, with just undefined ordering behaviour for concurrent writes (not our case). MSDN doesn't spell much out though. |
Hi, I see a fair bit of work has been done to make httplib threadsafe, wondering if that extends to Sink.is_writable()?
Context: trying to detect closed connections (in a set_content_provider setup) from another thread in llama.cpp. Our writes are still happening only on the http thread, but knowing when to cancel the processing would be amazing.
The text was updated successfully, but these errors were encountered: