Stream: project-ffi-unwind

Topic: posting the RFc


view this post on Zulip nikomatsakis (May 12 2020 at 21:34):

So, @BatmanAoD (Kyle Strand) -- is anything hold us back from posting this rfc?

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 17:39):

Sorry, I didn't realize I had Zulip closed yesterday! There are still two TODO items in the doc, and I did also want to add some kind of new user-friendly term for "drop glue".

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 17:39):

Or rather, for the property of a frame having drop glue that will execute if an unwind happens

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 18:41):

The two TODOs are for adding more background info on discussions prior to the formation of the project group, and explaining why we're not just stabilizing #[unwind(allowed)].

view this post on Zulip nikomatsakis (May 13 2020 at 19:06):

BatmanAoD (Kyle Strand) said:

Or rather, for the property of a frame having drop glue that will execute if an unwind happens

maybe we should call it a "pending" frame or something?

view this post on Zulip nikomatsakis (May 13 2020 at 19:06):

I guess though we want in particular a name for frames that have no work to do

view this post on Zulip nikomatsakis (May 13 2020 at 19:06):

"passive"?

view this post on Zulip nikomatsakis (May 13 2020 at 19:06):

I still don't hate inert, I have to admit

view this post on Zulip nikomatsakis (May 13 2020 at 19:07):

I don't know of any existing terminology for this, so it seems like we have to create some

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:15):

I don't "hate" inert either, but I think it's.... a good analogy that could probably fit a different concept better in the future. When I hear "inert" I think of chemicals that don't react with other chemicals. In our context, these frames don't "react with" an unwinding operation, so it's not a terrible analogy. But somehow it doesn't strike me as immediately self-explanatory.

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:15):

Maybe if it's qualified: "unwind-inert."

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:16):

Yeah, I guess that would resolve my main concern, which is that "inert" doesn't sound specifically related to unwinding, cleanup, stack frames, etc.

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:17):

(As a totally hand-wavy hypothetical example, "inert" could be used some day to refer to some property of threads that prevents them from interacting with other threads in an observable way.)

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:17):

(Here, "threads" are analogous to "chemicals", and some are "inert" while others are not)

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:18):

What do you think of my suggestion of "disposable"? Or some other word for ready-to-be-disposed-of?

view this post on Zulip BatmanAoD (Kyle Strand) (May 13 2020 at 19:24):

"trivial-drop"

view this post on Zulip nikomatsakis (May 13 2020 at 21:40):

"unwind-oblivious"?

view this post on Zulip nikomatsakis (May 13 2020 at 21:40):

"disposable" doesn't feel very clear to me, I can't tell whether it means that there is or is not drop code to run

view this post on Zulip nikomatsakis (May 13 2020 at 21:41):

"trivial" is not a bad word for this

view this post on Zulip nikomatsakis (May 13 2020 at 21:41):

certainly saying that a POD struct has trivial drop is pretty reasonable

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 15:39):

"drop-pure", because obviously introducing the concept of function purity will clear everything up :laughing:

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 15:39):

I kind of like "unwind-oblivious."

view this post on Zulip nikomatsakis (May 14 2020 at 16:37):

"POSF" -- plain old stack frame :)

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 16:38):

I kind of love that, actually

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 16:38):

Though "POS" always makes me think "piece of --"

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 16:38):

and then "point-of-sale"

view this post on Zulip nikomatsakis (May 14 2020 at 16:38):

BatmanAoD (Kyle Strand) said:

Though "POS" always makes me think "piece of --"

I was aware of this connotation :P

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 16:38):

Maybe just make the connection to PODs explicit? PODF

view this post on Zulip nikomatsakis (May 14 2020 at 16:39):

"Data frame"?

view this post on Zulip nikomatsakis (May 14 2020 at 16:39):

I do have to say that "plain old data" is one of my favorite C++ "technical terms"

view this post on Zulip nikomatsakis (May 14 2020 at 16:39):

at least to me it was immediately clear what it meant when I first heard it :)

view this post on Zulip nikomatsakis (May 14 2020 at 16:40):

I suppose the acronym goes a long way to making it obscure again though

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 16:42):

It's the only good one!

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 16:42):

Arguably

view this post on Zulip Josh Triplett (May 14 2020 at 17:49):

I'd be in favor of either "POD Frame" or "POF (plain old frame)".

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 17:51):

I think let's go with POF. It's a distinct enough concept that using the word "POD" might lead to a false sense of confidence that the term can be understood without an explanation. But "POF" looks similar enough to "POD" that it'll probably work as a mnemonic.

view this post on Zulip Amanieu (May 14 2020 at 17:52):

.. I kinda liked inert.. (but don't mind me, this is devolving into a bikeshed)

view this post on Zulip Amanieu (May 14 2020 at 17:53):

I don't think "plain old" is very descriptive at all. It works in C++ because "old" clearly refers to C, but we don't have that in Rust.

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 18:01):

Hmmmmmm

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 18:02):

"plain old" is really more of an idiom, I'd say, just meaning "basic" or "well-understood". The point is that there's a difference in C++ between objects that are "just" data and objects that are... not. Sure, POD structs are just C structs, but I don't think the "old" in POD actually refers to C.

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 18:03):

I think bikeshedding is useful in this case, because C++ has _so many_ bad names/acronyms, and we risk introducing yet another bad name/acronym to the systems programming domain if this terminology catches on more broadly.

view this post on Zulip BatmanAoD (Kyle Strand) (May 14 2020 at 18:04):

(I.e. I want to avoid another RAII/PIMPL/"zero-cost")

view this post on Zulip nikomatsakis (May 14 2020 at 18:43):

I think POF is good

view this post on Zulip nikomatsakis (May 14 2020 at 18:43):

I agree that I never thought of "old" as referring to C

view this post on Zulip nikomatsakis (May 14 2020 at 18:43):

but more the "it's just a plain old something" idiom, but I guess that is .. well .. idiomatic :)

view this post on Zulip BatmanAoD (Kyle Strand) (May 15 2020 at 02:43):

(deleted)

view this post on Zulip BatmanAoD (Kyle Strand) (May 27 2020 at 19:28):

@nikomatsakis @Amanieu @acfoltzer

Even though I don't think the RFC is ready yet for a PR on the RFC repo (sorry, I haven't worked on it since our last discussion), would any of you object to merging it in its current state into the master branch of the project repo?

view this post on Zulip acfoltzer (May 27 2020 at 19:28):

no objections here

view this post on Zulip BatmanAoD (Kyle Strand) (May 27 2020 at 19:29):

Also, Amanieu, did the discussion on "plain old" resolve your concern? At this point I am leaning toward POF

view this post on Zulip nikomatsakis (May 27 2020 at 19:55):

no objections @BatmanAoD (Kyle Strand)

view this post on Zulip Amanieu (May 27 2020 at 21:22):

shrug I still don't like it... but meh, I don't care enough to argue.

view this post on Zulip BatmanAoD (Kyle Strand) (May 30 2020 at 20:23):

Wrapping up the RFC draft: here's my attempt to summarize a few years of argument into a couple of paragraphs, with links should people want to read more. Do we believe this is sufficient? https://github.com/BatmanAoD/project-ffi-unwind/blob/Rfc-POF-terminology/rfcs/0000-c-unwind-abi.md#older-discussions-about-unwinding-through-extern-c-boundaries

view this post on Zulip BatmanAoD (Kyle Strand) (May 30 2020 at 20:25):

https://github.com/rust-lang/project-ffi-unwind/pull/29

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 03 2020 at 22:54):

@WG-ffi-unwind Not sure who saw my message above, but I think the RFC is about ready to go.

view this post on Zulip nikomatsakis (Jun 04 2020 at 14:03):

@BatmanAoD (Kyle Strand) nice! I missed that, will take a look at the PR

view this post on Zulip nikomatsakis (Jun 09 2020 at 09:36):

@BatmanAoD (Kyle Strand) ugh I forgot about this again -- looking now

view this post on Zulip nikomatsakis (Jun 09 2020 at 09:44):

Looks great, left a comment

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 09 2020 at 17:16):

Thanks!

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 09 2020 at 20:26):

@Amanieu I feel like I must have asked this before, but web searches aren't helping me refresh my memory: what is an asynchronous exception, and why is it called that?

view this post on Zulip Amanieu (Jun 09 2020 at 20:30):

Basically a signal caused by an external event, such as a timer or sent by another thread. And then throwing an exception from the signal handler. Basically it means an exception could occur at any point in your program.

view this post on Zulip Amanieu (Jun 09 2020 at 20:30):

Needless to say, we don't support that.

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 09 2020 at 20:36):

In the nounwind LangRef entry you quoted, wasn't the bit about async exceptions the reason you said longjmp on Windows would have "implementation defined semantics"?

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 16:54):

@nikomatsakis Do you have any reservations about merging my PR as-is? We can discuss during the meeting today whether we want to reconsider forced-unwinds before submitting an actual RFC.

view this post on Zulip nikomatsakis (Jun 11 2020 at 17:14):

@BatmanAoD (Kyle Strand) feel free to merge

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 11 2020 at 17:20):

:thumbs_up:

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 13 2020 at 07:03):

@nikomatsakis I've addressed your PR comments, though I didn't adhere very closely to your suggested phrasings. Please let me know if you'd like additional changes. (Or feel free to edit it directly.)

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 15 2020 at 20:35):

@nikomatsakis Saw your PR comments; do you think we're set to open the actual RFC PR?

view this post on Zulip nikomatsakis (Jun 16 2020 at 14:59):

@BatmanAoD (Kyle Strand) I think so, yes

view this post on Zulip BatmanAoD (Kyle Strand) (Jun 16 2020 at 15:43):

@WG-ffi-unwind https://github.com/rust-lang/rfcs/pull/2945


Last updated: Jan 26 2022 at 07:20 UTC