forked from JuliaLang/julia
-
Notifications
You must be signed in to change notification settings - Fork 2
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
[pull] master from JuliaLang:master #1806
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Expose the demanded world to the GeneratedFunctionStub caller, for users such as Cassette. If this argument is used, the user must return a CodeInfo with the min/max world field set correctly. Make the internal representation a tiny bit more compact also, removing a little bit of unnecessary metadata. Remove support for returning `body isa CodeInfo` via this wrapper, since it is impossible to return a correct object via the GeneratedFunctionStub since it strips off the world argument, which is required for it to do so. This also removes support for not inferring these fully (expand_early=false). Also answer method lookup queries about the future correctly, by refusing to answer them. This helps keeps execution correct as methods get added to the system asynchronously. This reverts "fix #25678: return matters for generated functions (#40778)" (commit 92c84bf), since this is no longer sensible to return here anyways, so it is no longer permitted or supported by this macro. Fixes various issues where we failed to specify the correct world. Note that the passed world may be `typemax(UInt)`, which demands that the generator must return code that is unspecialized (guaranteed to run correctly in any world). Co-authored-by: Jameson Nash <[email protected]>
We see Windows CI fail often here, and we don't actually need this memory--only the first thread should initialize it. (indeed, we were temporarily corrupting these data-structures in the process by reinitializing them, though that was not typically detectable.) From worker 7: Exception: EXCEPTION_ACCESS_VIOLATION at 0x7ffa26726e87 -- jl_makecontext at C:/workdir/src\win32_ucontext.c:67 From worker 7: in expression starting at C:\buildkite-agent\builds\win2k22-amdci6-6\julialang\julia-master\julia-ceffaee345\share\julia\test\ccall.jl:1066 From worker 7: jl_makecontext at C:/workdir/src\win32_ucontext.c:67 From worker 7: jl_install_thread_signal_handler at C:/workdir/src\signals-win.c:490 From worker 7: jl_init_root_task at C:/workdir/src\task.c:1568 From worker 7: ijl_adopt_thread at C:/workdir/src\threading.c:414 From worker 7: unknown function (ip: 000001d791a58969) From worker 7: uv__queue_work at /workspace/srcdir/libuv\src\threadpool.c:305 From worker 7: worker at /workspace/srcdir/libuv\src\threadpool.c:122 From worker 7: uv__thread_start at /workspace/srcdir/libuv\src/win\thread.c:111 From worker 7: beginthreadex at C:\Windows\System32\msvcrt.dll (unknown line) From worker 7: endthreadex at C:\Windows\System32\msvcrt.dll (unknown line) From worker 7: BaseThreadInitThunk at C:\Windows\System32\KERNEL32.DLL (unknown line) From worker 7: RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line) From worker 7: Allocations: 352796158 (Pool: 352389694; Big: 406464); GC: 722
Defaults to gcc after autodetection. Regression caused by ee6115b.
The test was relying on two particular non-guaranteed timing races: 1. That the 0.5s wait task was started within 0.5s of the timedwait starting. 2. That the timedwait finished within 0.5 seconds of its deadline. Neither of these are guaranteed. The second of these was already made non-fatal with a warning print. However, I don't like warning prints in tests. They should either pass or fail. Nobody looks at the output unless the tests fail, so change the tests to: 1. Add extra synchronization to solve the race condition (1) by making sure the sleep starts before the timedwait. 2. Instead of doing a long wait, just have a synchronization channel that will never be made active. In particular, the thing that this test checks is that the timeout in `timedwait` actually works, and doesn't return too early. This arrangement checks both of those properties without unduly tight timing constraints.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )