Skip to content
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

threads: expand thread-safe region for I/O #32309

Merged
merged 1 commit into from
Jun 21, 2019
Merged

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Jun 12, 2019

This should hopefully cover most I/O operations that go through libuv (meaning that other operations like using IOStream files aren't part of this PR), to make them thread-safe.

The UDPSocket implementation of many things has been always wrong, this also fixes them.

@vtjnash vtjnash requested a review from JeffBezanson June 12, 2019 21:41
@JeffBezanson JeffBezanson added io Involving the I/O subsystem: libuv, read, write, etc. multithreading Base.Threads and related functionality labels Jun 13, 2019
@musm
Copy link
Contributor

musm commented Jun 14, 2019

Does this make function such as uv_os_homedir which libuv states are not thread safe, thread-safe in Julia?

@vtjnash
Copy link
Member Author

vtjnash commented Jun 14, 2019

I wouldn't rely too closely on the libuv docs 😜. I think that warning seems to have gotten fixed before the PR was merged. I'm not sure why the message got left in. Perhaps you'd like to delete it for them?

@vtjnash vtjnash marked this pull request as ready for review June 18, 2019 13:02
This should hopefully cover most I/O operations which go through libuv to make them thread-safe.

There is no scaling here, just one big global lock, so expect
worse-than-single-threaded performance if doing I/O on multiple threads (as
compared to doing the same work on one thread). The intention is to handle
performance improvement incrementally later.

It also necessarily redesigns parts of the UDPSocket implementation
to properly handle concurrent (single-threaded) usage, as a necessary
part of making it handle parallel (thread-safe) usage.
@JeffBezanson JeffBezanson merged commit 58bafe4 into master Jun 21, 2019
@JeffBezanson JeffBezanson deleted the jn/thread-io branch June 21, 2019 17:17
vtjnash added a commit that referenced this pull request Jun 26, 2019
After #32309, we became much more eager to forget about normal errors
and more eager to throw an EOFError at the wrong place.
This is intended to fix that oversight.
vtjnash added a commit that referenced this pull request Jun 27, 2019
After #32309, we became much more eager to forget about normal errors
and more eager to throw an EOFError at the wrong place.
This is intended to fix that oversight.
vtjnash added a commit that referenced this pull request Jul 11, 2019
After #32309, we became much more eager to forget about normal errors
and more eager to throw an EOFError at the wrong place.
This is intended to fix that oversight.
vchuravy added a commit that referenced this pull request Apr 21, 2020
It is noted as a non-OS stream, but has also been a subtype
of LibuvStream since forever. #32309 did not add the `readerror`
field.
JeffBezanson pushed a commit that referenced this pull request Apr 22, 2020
It is noted as a non-OS stream, but has also been a subtype
of LibuvStream since forever. #32309 did not add the `readerror`
field.
KristofferC pushed a commit that referenced this pull request May 10, 2020
It is noted as a non-OS stream, but has also been a subtype
of LibuvStream since forever. #32309 did not add the `readerror`
field.

(cherry picked from commit de04210)
Keno pushed a commit that referenced this pull request Jun 5, 2024
This should hopefully cover most I/O operations which go through libuv to make them thread-safe.

There is no scaling here, just one big global lock, so expect
worse-than-single-threaded performance if doing I/O on multiple threads (as
compared to doing the same work on one thread). The intention is to handle
performance improvement incrementally later.

It also necessarily redesigns parts of the UDPSocket implementation
to properly handle concurrent (single-threaded) usage, as a necessary
part of making it handle parallel (thread-safe) usage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
io Involving the I/O subsystem: libuv, read, write, etc. multithreading Base.Threads and related functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants