Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upsync::Once and panicking closure #31688
Comments
This comment has been minimized.
This comment has been minimized.
|
triage: I-nominated |
rust-highfive
added
the
I-nominated
label
Feb 16, 2016
alexcrichton
added
the
T-libs
label
Feb 16, 2016
This comment has been minimized.
This comment has been minimized.
|
I don't really have an opinion on what the semantics should be in this case, but I'm curious what others think! |
This comment has been minimized.
This comment has been minimized.
|
I personally think the current behavior is fine (a common use case for Once it to initialize something, and if the closure panics it probably hasn't been initialized), but we should document it. |
This comment has been minimized.
This comment has been minimized.
|
panic inside call_once is a very broken scenario. Maybe it would only help authors of critical unsafe code if we ensured the closure could only be called once ever. The closure call could be enforced to abort on panic (it should be a "noexcept" zone).
|
This comment has been minimized.
This comment has been minimized.
|
Interesting, it's not broken because of FnOnce, the actual closure value is only called once (or never). |
This comment has been minimized.
This comment has been minimized.
|
cc me |
This comment has been minimized.
This comment has been minimized.
|
I prefer poisoning it, without any options to unpoison. Alternately, just leaving it alone. |
This comment has been minimized.
This comment has been minimized.
|
The libs team discussed this during triage yesterday and we didn't necessarily reach any concrete conclusion. As @brson mentioned we talked about how we may want to just poison a |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 18, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 18, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 25, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 25, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 25, 2016
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Mar 26, 2016
Manishearth
added a commit
to Manishearth/rust
that referenced
this issue
Mar 26, 2016
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Mar 26, 2016
bors
added a commit
that referenced
this issue
Mar 26, 2016
bors
closed this
in
#32325
Mar 27, 2016
This comment has been minimized.
This comment has been minimized.
|
This is marked as the tracking issue for the |
This comment has been minimized.
This comment has been minimized.
|
Ah it's probably best to open a new tracking issue, would you be interested in doing so @durka? |
tmiasko commentedFeb 15, 2016
The documentation for sync::Once does not clarify what happens if given closure
panics. Currently I would rather expect that call_once will execute the closure
only once, whether it panics or not. But this is not what happens:
Prints:
Either way documentation needs a slight improvement. And additionally code if
it is not a desired behaviour. As a side comment I will note that this
behaviour differs between languages. In C++ for example std::call_once to
proceed must not exit via exception, in Go on the other hand exiting via panic
counts as successful execution.