Rebase #1
Merged
Rebase #1
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
Add docs for RawFD
Docs for RoundFromZero and some xrefs
* Update index.md
also disable "local declared twice" error This permits declaring a loop variable as local inside the loop, which was used during 0.7 to get the new scope behavior.
* Refactor `REPLMode.parse_quotes`
* Refactor: APIOptions should be a dictionary * Fix `do_activate!` interface * Update tests: APIOptions is a dictionary * Allow more flexibility for REPL `do_<>` functions
a more descriptive error, instead of a BoundsError, in the case where DEPOT_PATH is empty.
* Fix parser * Add test for REPL `?<command>` help syntax
* remove ability to give a git revision to devved packages * wip
Fix History `eye` deprecation PR: should be 24415
Alloc opt got smarter. This makes a bunch of tests basically useless because they get optimized out entirely, but keep them to make sure it stays that way.
Add `lit` and `FileCheck` to tools and run llvmpasses by default
* Update `NEWS.md` for `Libdl.{dlopen,dlsym}` changes
* Fix `dlopen()` and `dlsym()` backwards incompatibility
* Update tests
Compiler.return_type is a bit of an odd beast because we basically treat it like a built-in, but it's defined in the compiler. When working on inference, it can be useful to load a second copy of inference with the new changes (e.g. to test changes before the changes are capable of running correctly on all input). This works quite well, but was causing problems with return type, because Base's notion of return_type and the second inference copy's notion of return_type were different. This patch adds a simple is_return_type(f) predicate that we can overload in our second inference copy in order to make it recognize both Core.Compiler.return_type and return_type (from the second copy's perspective as the return_type builtin).
We're not consistent about whether singletons are represented as Consts or as types (particularly after round-tripping through a representation that doesn't have `Const`). As such, it is easy for the compiler to miss calls.
This caused the optimizer to miss some optimization opportunities.
* write log to file * Use julia-repl for highlighting, fix indentation
Support for vectors of tracked pointer was incomplete in the GC placement pass. Try to fix as many cases as possible and add some tests. A refactor to make all of this nicer (vectors weren't originally part of the implementation might be good), but for now, let's get it correct first. Fixes #28536
* doc: fix accumulate examples not using the init keyword * add links (KristofferC)
pablosanjose
pushed a commit
that referenced
this pull request
Jul 15, 2020
This reuses the machinery that gives good stacktraces when a user
calls wait on a Task. Since bind internally uses _wait2, this
machinery is bypassed currently.
Currently, julia throws an uninformative stacktrace in this situation:
julia> c = Channel(_ -> error("foo"))
Channel{Any}(sz_max:0,sz_curr:0)
julia> for i in c end
ERROR: foo
Stacktrace:
[1] iterate(::Channel{Any}) at ./channels.jl:459
[2] top-level scope at ./REPL[2]:1
With this change, the stacktrace is much more informative:
julia> for i in c end
ERROR: TaskFailedException:
foo
Stacktrace:
[1] error(::String) at ./error.jl:33
[2] (::var"#1#2")(::Channel{Any}) at ./REPL[4]:1
[3] (::Base.var"JuliaLang#652#653"{var"#1#2",Channel{Any}})() at ./channels.jl:129
Stacktrace:
[1] check_channel_state at ./channels.jl:167 [inlined]
[2] take_unbuffered(::Channel{Any}) at ./channels.jl:405
[3] take! at ./channels.jl:383 [inlined]
[4] iterate(::Channel{Any}, ::Nothing) at ./channels.jl:449
[5] iterate(::Channel{Any}) at ./channels.jl:448
[6] top-level scope at ./REPL[5]:1
pablosanjose
pushed a commit
that referenced
this pull request
Jan 27, 2024
…#51489) This exposes the GC "stop the world" API to the user, for causing a thread to quickly stop executing Julia code. This adds two APIs (that will need to be exported and documented later): ``` julia> @CCall jl_safepoint_suspend_thread(#=tid=#1::Cint, #=magicnumber=JuliaLang#2::Cint)::Cint # roughly tkill(1, SIGSTOP) julia> @CCall jl_safepoint_resume_thread(#=tid=#1::Cint)::Cint # roughly tkill(1, SIGCONT) ``` You can even suspend yourself, if there is another task to resume you 10 seconds later: ``` julia> ccall(:jl_enter_threaded_region, Cvoid, ()) julia> t = @task let; Libc.systemsleep(10); print("\nhello from $(Threads.threadid())\n"); @CCall jl_safepoint_resume_thread(0::Cint)::Cint; end; ccall(:jl_set_task_tid, Cint, (Any, Cint), t, 1); schedule(t); julia> @time @CCall jl_safepoint_suspend_thread(0::Cint, 2::Cint)::Cint hello from 2 10 seconds (6 allocations: 264 bytes) 1 ``` The meaning of the magic number is actually the kind of stop that you want: ``` // n.b. suspended threads may still run in the GC or GC safe regions // but shouldn't be observable, depending on which enum the user picks (only 1 and 2 are typically recommended here) // waitstate = 0 : do not wait for suspend to finish // waitstate = 1 : wait for gc_state != 0 (JL_GC_STATE_WAITING or JL_GC_STATE_SAFE) // waitstate = 2 : wait for gc_state != 0 (JL_GC_STATE_WAITING or JL_GC_STATE_SAFE) and that GC is not running on that thread // waitstate = 3 : wait for full suspend (gc_state == JL_GC_STATE_WAITING) -- this may never happen if thread is sleeping currently // if another thread comes along and calls jl_safepoint_resume, we also return early // return new suspend count on success, 0 on failure ``` Only magic number 2 is currently meaningful to the user though. The difference between waitstate 1 and 2 is only relevant in C code which is calling this from JL_GC_STATE_SAFE, since otherwise it is a priori known that GC isn't running, else we too would be running the GC. But the distinction of those states might be useful if we have a concurrent collector. Very important warning: if the stopped thread is holding any locks (e.g. for codegen or types) that you then attempt to acquire, your thread will deadlock. This is very likely, unless you are very careful. A future update to this API may try to change the waitstate to give the option to wait for the thread to release internal or known locks.
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.
No description provided.