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

[pull] master from JuliaLang:master #1806

Merged
merged 9 commits into from
Mar 24, 2023
Merged

Conversation

pull[bot]
Copy link

@pull pull bot commented Mar 24, 2023

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

KristofferC and others added 9 commits March 24, 2023 14:50
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.
@pull pull bot added the ⤵️ pull label Mar 24, 2023
@pull pull bot merged commit 1b7f98a into MLH-Fellowship:master Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants