Stream: project-ffi-unwind

Topic: weekly meeting


nikomatsakis (Oct 31 2019 at 17:36, on Zulip):

Hey @WG-ffi-unwind -- are we going to have a sync this week?

nikomatsakis (Oct 31 2019 at 17:38, on Zulip):

er, I see @Kyle Strand you wrote a few comments in the "lang team sync" topic...

nikomatsakis (Oct 31 2019 at 17:38, on Zulip):

let's use this one for weekly meetings instead? seems like a better name :)

nikomatsakis (Oct 31 2019 at 17:38, on Zulip):

so where are we at

nikomatsakis (Oct 31 2019 at 17:39, on Zulip):

I guess @Kyle Strand I should just merge https://github.com/rust-lang/project-ffi-unwind/pull/16 ?

Kyle Strand (Oct 31 2019 at 17:40, on Zulip):

Sounds good!

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

I think this is basically the same content as https://github.com/rust-lang/rfcs/pull/2797, right?

Kyle Strand (Oct 31 2019 at 17:42, on Zulip):

I feel like the PR is close to having agreement, which is nice (I am guessing Centril is holding off on approving until the scope questions are addressed)

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

I haven't revisited since my last round of comments

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

did you modify the text at all in response to those?

nikomatsakis (Oct 31 2019 at 17:42, on Zulip):

I should check

Kyle Strand (Oct 31 2019 at 17:43, on Zulip):

I guess Kyle Strand I should just merge https://github.com/rust-lang/project-ffi-unwind/pull/16 ?

You should always merge my PRs :wink:

Kyle Strand (Oct 31 2019 at 17:43, on Zulip):

No, I haven't made any modifications since then

nikomatsakis (Oct 31 2019 at 17:43, on Zulip):

haven't written anything up yet, but my "summarizing discussions" file and the new PR itself might be sufficient anyway

@Kyle Strand which "summarizing discussions" file did you mean? oh, the one that summarized all of zulip?

Kyle Strand (Oct 31 2019 at 17:43, on Zulip):

But those were the only two outstanding concerns

Kyle Strand (Oct 31 2019 at 17:43, on Zulip):

yep

nikomatsakis (Oct 31 2019 at 17:43, on Zulip):

ok, I feel like there was some discussion I thought would be good to summarize specifically..not sure which it was now :)

nikomatsakis (Oct 31 2019 at 17:44, on Zulip):

"catching foreign exceptions", that topic

nikomatsakis (Oct 31 2019 at 17:44, on Zulip):

I guess the other lang team update is that we've extended the set of arguments somewhat around "C unwind" vs "C noexcept" etc

Kyle Strand (Oct 31 2019 at 17:45, on Zulip):

Yes

nikomatsakis (Oct 31 2019 at 17:46, on Zulip):

oh I see there have been some new additions as well

nikomatsakis (Oct 31 2019 at 17:46, on Zulip):

I have to read those and see if I find them persuasive

nikomatsakis (Oct 31 2019 at 17:46, on Zulip):

one thing I would like to have is a list of which functions use "C" but actually can unwind

nikomatsakis (Oct 31 2019 at 17:47, on Zulip):

I guess longjmp is such an example :)

nikomatsakis (Oct 31 2019 at 17:47, on Zulip):

(at least on MSVC)

Kyle Strand (Oct 31 2019 at 17:48, on Zulip):

I have to read those and see if I find them persuasive

FWIW I believe the HackMD updates capture the important bits of the conversation; reading the whole thread is likely not an optimal use of time

nikomatsakis (Oct 31 2019 at 17:48, on Zulip):

I do not mean to read any threads :)

Kyle Strand (Oct 31 2019 at 17:49, on Zulip):

Perfect!

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

which thread are you referring to, "noexcept-like feature"? :)

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

Adding the guarantee to the language that extern "C" do not unwind has the same expressive power as C++ noexcept keyword, but much worse ergonomics.

Kyle Strand (Oct 31 2019 at 17:49, on Zulip):

Yes

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

I am struggling with this statement :)

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

in particular, I'd lke to see examples of the ergonomics?

acfoltzer (Oct 31 2019 at 17:49, on Zulip):

hey, sorry I'm late. catching up now

nikomatsakis (Oct 31 2019 at 17:49, on Zulip):

maybe they're below, but I got lost in the proof..

Kyle Strand (Oct 31 2019 at 17:49, on Zulip):

Oh, for that it might actually be useful to look at the examples gnzlbg gave in the thread

Kyle Strand (Oct 31 2019 at 17:50, on Zulip):

https://rust-lang.zulipchat.com/#narrow/stream/210922-wg-ffi-unwind/topic/noexcept-like.20feature/near/179520449

Kyle Strand (Oct 31 2019 at 17:50, on Zulip):

and

https://rust-lang.zulipchat.com/#narrow/stream/210922-wg-ffi-unwind/topic/noexcept-like.20feature/near/179444817

nikomatsakis (Oct 31 2019 at 17:50, on Zulip):

okI think the argument is:

nikomatsakis (Oct 31 2019 at 17:51, on Zulip):

you might like to guarantee "no unwinding" in cases where no C code is involved

Kyle Strand (Oct 31 2019 at 17:51, on Zulip):

Yes

nikomatsakis (Oct 31 2019 at 17:51, on Zulip):

that's an interesting argument

Kyle Strand (Oct 31 2019 at 17:51, on Zulip):

and the idea is that introducing this feature "accidentally" by way of ABI strings would be detrimental

Kyle Strand (Oct 31 2019 at 17:51, on Zulip):

"detrimental" may be too strong

Kyle Strand (Oct 31 2019 at 17:53, on Zulip):

Generally, I do think that if/when we introduce a feature to cause functions to automatically abort-on-panic, it should be applicable to functions regardless of the ABI

acfoltzer (Oct 31 2019 at 17:54, on Zulip):

okay, caught up on this thread at least. I have had even less time than I was expecting given our current demo crunch. I'm excited by #16!

nikomatsakis (Oct 31 2019 at 17:54, on Zulip):

That seems true but it doesn't mean we can't also the ABI

nikomatsakis (Oct 31 2019 at 17:55, on Zulip):

but I see the point

nikomatsakis (Oct 31 2019 at 17:55, on Zulip):

I've summarized here:

You might like to avoid unwinding of Rust functions, too

We discussed how unsafe code in particular must be careful to be "unwind safe", but this applies not just to "C" functions but really to any Rust function. Therefore, we might like to have a feature that guarantees that some callee cannot unwind. But do we really want to use the ABI string to contrl this in the more general case?

Kyle Strand (Oct 31 2019 at 17:55, on Zulip):

I think the quote from Nick L that I added to the HackMD doc captures the concern: "FFI is not a sandbox"

Kyle Strand (Oct 31 2019 at 17:56, on Zulip):

which is to say, the lang team has been planning to make it a sandbox for a long time, but at least one LLVM dev thought that sounded like the wrong approach. Not sure what weight to assign that fact.

acfoltzer (Oct 31 2019 at 17:57, on Zulip):

sandbox in what sense, here?

Kyle Strand (Oct 31 2019 at 17:57, on Zulip):

Sandboxing unwinding ops to prevent them from escaping

nikomatsakis (Oct 31 2019 at 17:57, on Zulip):

I mean it doesn't actually "prevent", of course, since it would be "UB"

Kyle Strand (Oct 31 2019 at 17:57, on Zulip):

by changing the semantics of a function (i.e. inserting a shim that does something)

nikomatsakis (Oct 31 2019 at 17:57, on Zulip):

I think it's more accurate to say that the ABI is promising not to unwind

nikomatsakis (Oct 31 2019 at 17:57, on Zulip):

it is most definitely not sandboxing it

nikomatsakis (Oct 31 2019 at 17:58, on Zulip):

it doesn't seem that different frm any other type

Kyle Strand (Oct 31 2019 at 17:58, on Zulip):

Oh, there's a misunderstanding here. The "sandbox" concern is about the planned behavior of extern "C", which is to insert an abort-on-unwind shim (which is well defined)

acfoltzer (Oct 31 2019 at 17:58, on Zulip):

got it. yeah, seems like the best we can do is insert shims for the unwinding mechanisms we're aware of, but that's certainly not a guarantee

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

Oh, there's a misunderstanding here. The "sandbox" concern is about the planned behavior of extern "C", which is to insert an abort-on-unwind shim (which is well defined)

that is only true for

extern "C" fn foo() { }

but not calls to some random extern "C" fn

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

it seems like a key point

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

because the strongest argument against extern "C" unwinding has precisely to do with this

Kyle Strand (Oct 31 2019 at 17:59, on Zulip):

True.

nikomatsakis (Oct 31 2019 at 17:59, on Zulip):

at least what I see as the strongest argument

Kyle Strand (Oct 31 2019 at 18:00, on Zulip):

Hm....I would see that as an argument for extern "C" unwinding: since the abort-shim can only be inserted in Rust functions, that would make extern "C" inconsistent.

nikomatsakis (Oct 31 2019 at 18:00, on Zulip):

which is that -Cpanic=abort must either introduce shims on calls to extern "C" functions to abort or else it means that -Cpanic=abort can cause UB

nikomatsakis (Oct 31 2019 at 18:00, on Zulip):

for code that otherwise worked

nikomatsakis (Oct 31 2019 at 18:00, on Zulip):

and then there is the question of the cost of said shims in terms of code size (I am not sure what the answer is there)

Kyle Strand (Oct 31 2019 at 18:00, on Zulip):

I'm talking about the non-panic=abort case, i.e., the behavior originally introduced in 1.24.0

acfoltzer (Oct 31 2019 at 18:01, on Zulip):

those shims might also depend on platform/library calls that are exactly the kinds of things that, say, embedded would want to avoid

nikomatsakis (Oct 31 2019 at 18:01, on Zulip):

Hm....I would see that as an argument for extern "C" unwinding: since the abort-shim can only be inserted in Rust functions, that would make extern "C" inconsistent.

fair, although you could view that as just an argument against adding the shims (to avoid inconsistency)

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

those shims might also depend on platform/library calls that are exactly the kinds of things that, say, embedded would want to avoid

I suppose that if you are on a platform that has no unwinding mechanism, then that's a different scenario

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

(not sure if that's what you were implying)

Kyle Strand (Oct 31 2019 at 18:02, on Zulip):

Right -- without the shims, extern "C" would unwind

Kyle Strand (Oct 31 2019 at 18:02, on Zulip):

instead of aborting

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

the point is that throws of foreign exceptions are out of our control, ultimately, so -Cpanic=abort can't change them to aborts

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

Right -- without the shims, extern "C" would unwind

it would just be UB al the time

nikomatsakis (Oct 31 2019 at 18:02, on Zulip):

(presuming we added "C unwind", I mean)

Kyle Strand (Oct 31 2019 at 18:03, on Zulip):

Re: panic=abort and calling foreign functions that unwind, I'd like to know whether noexcept in LLVM actually causes undefined behavior there. E.g. we already know it doesn't interfere with longjmp on Windows

nikomatsakis (Oct 31 2019 at 18:04, on Zulip):

@gnzlbg are you around?

acfoltzer (Oct 31 2019 at 18:04, on Zulip):

I don't like appealing to the authority of the C/C++ world, but if my -fno-exceptions code called a function in a library that threw an exception, I wouldn't expect anything other than UB

gnzlbg (Oct 31 2019 at 18:04, on Zulip):

@nikomatsakis more or less

nikomatsakis (Oct 31 2019 at 18:04, on Zulip):

@acfoltzer yeah but that's the scenario I think we're trying to avoid

Kyle Strand (Oct 31 2019 at 18:04, on Zulip):

That's certainly my default assumption in that world :laughing:

nikomatsakis (Oct 31 2019 at 18:04, on Zulip):

that is an alternative though

gnzlbg (Oct 31 2019 at 18:05, on Zulip):

I haven't read this thread

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

@gnzlbg what I specifically wanted to ask you is

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

do you have a list somewhere of libc functions that might unwind?

gnzlbg (Oct 31 2019 at 18:05, on Zulip):

yes, I posted it on the other thread, wait a sec

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

is it like "any pthread function", in the case of cancelation occuring?

nikomatsakis (Oct 31 2019 at 18:05, on Zulip):

aah, sorry

gnzlbg (Oct 31 2019 at 18:06, on Zulip):

http://man7.org/linux/man-pages/man7/pthreads.7.html

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

I don't like appealing to the authority of the C/C++ world, but if my -fno-exceptions code called a function in a library that threw an exception, I wouldn't expect anything other than UB

to expand on this -- the question is basically whether -Cpanic=abort should be the kind of thing that users have to be very careful and knowledge about (like certain details of target-feature), or is it something you can enable casually?

gnzlbg (Oct 31 2019 at 18:06, on Zulip):

s it like "any pthread function", in the case of cancelation occuring?

No, its more like any C or POSIX API that can do a system call

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

@gnzlbg presumably longjmp also falls into this category?

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

No, its more like any C or POSIX API that can do a system call

woah wait hold up :)

gnzlbg (Oct 31 2019 at 18:06, on Zulip):

in that link go for cancellation points, and there is a huge list: poll, open, sleep,

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

that's a fairly broad category

nikomatsakis (Oct 31 2019 at 18:06, on Zulip):

ok, that's interesting

gnzlbg (Oct 31 2019 at 18:07, on Zulip):

yes, there are a lot of APIs that are required to be cancellation points, and many that are allowed to be

gnzlbg (Oct 31 2019 at 18:07, on Zulip):

e.g. printf can be a cancellation point

gnzlbg (Oct 31 2019 at 18:07, on Zulip):

basically it works like a garbage collector would in say Java

gnzlbg (Oct 31 2019 at 18:08, on Zulip):

when you cancel a thread, the threading run-time will do so, once that thread calls a function from the C run-time

gnzlbg (Oct 31 2019 at 18:08, on Zulip):

if a thread doesn't do that, the run-time has little options to cancel the thread because the thread is doing other stuff

gnzlbg (Oct 31 2019 at 18:08, on Zulip):

so by calling open, you are yielding to the run-time, and might do a context switch, and at that point the runtime might say "you are cancelled"

acfoltzer (Oct 31 2019 at 18:09, on Zulip):

that makes a lot of sense but the implications are kind of horrifying

gnzlbg (Oct 31 2019 at 18:10, on Zulip):

I mean, the "anything that can do a context switch is a cancellation point" is my rule of thumb

gnzlbg (Oct 31 2019 at 18:10, on Zulip):

There are like ~50 or so POSIX APIs that can be cancellation points

gnzlbg (Oct 31 2019 at 18:10, on Zulip):

there are many C APIs that are not. Those 50 APIs are used a lot though.

gnzlbg (Oct 31 2019 at 18:11, on Zulip):

Then there is the issue of what happens if the thread doesn't call a cancellation point for too long

centril (Oct 31 2019 at 18:11, on Zulip):

I feel like the PR is close to having agreement, which is nice (I am guessing Centril is holding off on approving until the scope questions are addressed)

@Kyle Strand I checked my box 2 days ago but it seems rfcbot didn't record it

nikomatsakis (Oct 31 2019 at 18:11, on Zulip):

@gnzlbg thanks I will add those details to the hackmd

nikomatsakis (Oct 31 2019 at 18:11, on Zulip):

so I think i've revised my opinion

nikomatsakis (Oct 31 2019 at 18:11, on Zulip):

I used to think this was open-and-shut

centril (Oct 31 2019 at 18:11, on Zulip):

There; the "RFC" is in FCP now

nikomatsakis (Oct 31 2019 at 18:12, on Zulip):

but now I think that it's unclear

gnzlbg (Oct 31 2019 at 18:12, on Zulip):

there is the question whether we want to support those cancellation points

nikomatsakis (Oct 31 2019 at 18:13, on Zulip):

yes

gnzlbg (Oct 31 2019 at 18:13, on Zulip):

for example, we could say that using pthread_cancel with libstd threads is UB

gnzlbg (Oct 31 2019 at 18:13, on Zulip):

that's kind of the status quo right now

nikomatsakis (Oct 31 2019 at 18:13, on Zulip):

I also used to think that "C noexcept" was a "no brainer" to include, but now I think that is less clear -- the idea of just having "C" (which suppors unwinding in the platform default way) is somewhat appealing, and maybe having some form of no-except that is orthogonal to ABI

nikomatsakis (Oct 31 2019 at 18:13, on Zulip):

right, I think that is one of the options

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

I mean I think pthread cancelation is a terrible ida anyway :)

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

but .. maybe that's not for me to decide

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

I at least didn't appreciate that unwinding was used in this way

Kyle Strand (Oct 31 2019 at 18:14, on Zulip):

I also used to think that "C noexcept" was a "no brainer" to include, but now I think that is less clear -- the idea of just having "C" (which suppors unwinding in the platform default way) is somewhat appealing, and maybe having some form of no-except that is orthogonal to ABI

Yes, I don't believe it's a "no brainer" either :smile:

gnzlbg (Oct 31 2019 at 18:14, on Zulip):

might be a libs-team issue

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

I feel like it merits a more focused discussion

centril (Oct 31 2019 at 18:14, on Zulip):

but .. maybe that's not for me to decide

@nikomatsakis general point: I think it's fine to have opinionated language design

gnzlbg (Oct 31 2019 at 18:14, on Zulip):

note that if a thread doesn't call a C run-time function for a while, the run-time might send a signal and just kill it

nikomatsakis (Oct 31 2019 at 18:14, on Zulip):

one thing that I think would be highly relevant would be data

centril (Oct 31 2019 at 18:14, on Zulip):

(As an also-Haskeller it is predictable for me to say that however)

nikomatsakis (Oct 31 2019 at 18:15, on Zulip):

I would be interestd -- since @Taylor Cramer cares a lot about this -- to gather data on fuschia builds without -Cpanic=abort, for example

nikomatsakis (Oct 31 2019 at 18:15, on Zulip):

which is kind of a "worse case' :)

nikomatsakis (Oct 31 2019 at 18:16, on Zulip):

might be a libs-team issue

actually it occurs to me that

nikomatsakis (Oct 31 2019 at 18:16, on Zulip):

this is also an argument for #[unwind(allow)]

nikomatsakis (Oct 31 2019 at 18:16, on Zulip):

i.e., if we say that "C" ABI permits unwinding, but the function must be declared to unwind, and by-pointer calls assume it may unwind

centril (Oct 31 2019 at 18:16, on Zulip):

@nikomatsakis huh?

nikomatsakis (Oct 31 2019 at 18:17, on Zulip):

then the libc functions can become #[unwind(allow)]

nikomatsakis (Oct 31 2019 at 18:17, on Zulip):

in a backwards compatible way

gnzlbg (Oct 31 2019 at 18:17, on Zulip):

yes, that was also another possible design

centril (Oct 31 2019 at 18:17, on Zulip):

libc's backwards compatibility policies are not something I care about

Kyle Strand (Oct 31 2019 at 18:18, on Zulip):

Niko, do you mean that without the unwind(allow) annotation, extern "C" fn ... { /* Rust code */ } would insert the abort-shim?

Kyle Strand (Oct 31 2019 at 18:18, on Zulip):

libc's backwards compatibility policies are not something I care about

Noted, but that's not universal!

nikomatsakis (Oct 31 2019 at 18:18, on Zulip):

yes but also

nikomatsakis (Oct 31 2019 at 18:18, on Zulip):

it's not just about libc back-compat

Kyle Strand (Oct 31 2019 at 18:19, on Zulip):

Centril, I believe you previously objected to extern "C" <Rust fn> inserting the shim, but extern "C" being assumed to "possibly unwind", being inconsistent?

nikomatsakis (Oct 31 2019 at 18:19, on Zulip):

I guess it's a variant of the "it's simpler to have one ABI that supports the things the ABI supports"

centril (Oct 31 2019 at 18:19, on Zulip):

@nikomatsakis btw, 10 min to pre-triage

nikomatsakis (Oct 31 2019 at 18:19, on Zulip):

i.e., all extern "C" functions can unwind (the ABI permits it) -- but if we know the callee, we may know they won't

nikomatsakis (Oct 31 2019 at 18:19, on Zulip):

you could also argue for the opposite default

nikomatsakis (Oct 31 2019 at 18:20, on Zulip):

which is where @Amanieu started

nikomatsakis (Oct 31 2019 at 18:20, on Zulip):

ok, I'm seeing the case for that a bit stronger

nikomatsakis (Oct 31 2019 at 18:21, on Zulip):

I want to spend some time thinking on how to re-organize the hackmd now to better bring these ideas out

centril (Oct 31 2019 at 18:22, on Zulip):

@Kyle Strand "the shim" ?

centril (Oct 31 2019 at 18:22, on Zulip):

the abort on unwind shim?

centril (Oct 31 2019 at 18:22, on Zulip):

or some other?

centril (Oct 31 2019 at 18:22, on Zulip):

That sentence wasn't clear enough for me to understand & answer

Kyle Strand (Oct 31 2019 at 18:23, on Zulip):

Sorry, yes, the abort-on-unwind shim.

centril (Oct 31 2019 at 18:23, on Zulip):

@nikomatsakis From a purely compiler & spec POV I think a distinct ABI string is simplest at least; it is using an existing infra rather than inventing a new one

centril (Oct 31 2019 at 18:24, on Zulip):

@Kyle Strand the abort-on-unwind shim is mandatory if unwinding is not allowed for soundness

Kyle Strand (Oct 31 2019 at 18:24, on Zulip):

nikomatsakis From a purely compiler & spec POV I think a distinct ABI string is simplest at least; it is using an existing infra rather than inventing a new one

Removing nounwind from LLVM code generation for extern "C", and stabilizing the unwind(allowed/abort) attributes, is even simpler, isn't it?

centril (Oct 31 2019 at 18:25, on Zulip):

I don't believe so

nikomatsakis (Oct 31 2019 at 18:26, on Zulip):

@centril when you invoke a function, we already have a unique type that represents known callees

centril (Oct 31 2019 at 18:26, on Zulip):

The "Rust" ABI already does switch nounwind off, so that logic already exists wrt. pattern matching on ABIs

nikomatsakis (Oct 31 2019 at 18:26, on Zulip):

so it's not hard to distinguish "call by pointer" from "call to known function"

Kyle Strand (Oct 31 2019 at 18:26, on Zulip):

Kyle Strand the abort-on-unwind shim is mandatory if unwinding is not allowed for soundness

I'm talking about the case where unwinding is allowed. I remember you saying that this combination would be inconsistent:

Kyle Strand (Oct 31 2019 at 18:27, on Zulip):

...and I believe that's the combination Niko is describing above.

Kyle Strand (Oct 31 2019 at 18:27, on Zulip):

i.e., if we say that "C" ABI permits unwinding, but the function must be declared to unwind, and by-pointer calls assume it may unwind

in this message

centril (Oct 31 2019 at 18:27, on Zulip):

that seems inconsistent yes

Kyle Strand (Oct 31 2019 at 18:28, on Zulip):

Okay, glad I remembered correctly :smile:

nikomatsakis (Oct 31 2019 at 18:28, on Zulip):

I thought so, but now i'm not so sure.

nikomatsakis (Oct 31 2019 at 18:28, on Zulip):

It also depends a lot on the defaults.

centril (Oct 31 2019 at 18:28, on Zulip):

@nikomatsakis You are talking about the distinction between FnDef and FnPtr?

nikomatsakis (Oct 31 2019 at 18:29, on Zulip):

But it seems like a big part of this question is also a matter of costs -- like, if the worst part of "C unwinds" is the need for an abort shim on call sites, how much does that really cost in actual programs? can we readily measure that?

nikomatsakis (Oct 31 2019 at 18:29, on Zulip):

it seems eminently measurable

centril (Oct 31 2019 at 18:30, on Zulip):

@nikomatsakis at any rate, we have pre-triage now :slight_smile:

nikomatsakis (Oct 31 2019 at 18:30, on Zulip):

yes, I know.

gnzlbg (Oct 31 2019 at 18:33, on Zulip):

one open question with the unwind by default, nounwind opt-in, is how to apply #[unwind(aborts)] to function pointers

gnzlbg (Oct 31 2019 at 18:33, on Zulip):

but that's more a syntactic issue

Amanieu (Oct 31 2019 at 19:07, on Zulip):

For #[unwind(aborts)], it is the responsibility of the callee to ensure that it aborts instead of unwinding. From the caller's point of view it's just a nounwind function. So there isn't much to do with function pointers: by default they can unwind and specifying nounwind function pointers probably isn't worth the trouble.

gnzlbg (Oct 31 2019 at 19:17, on Zulip):

maybe, that was an unresolved question last time

gnzlbg (Oct 31 2019 at 19:18, on Zulip):

in case we wanted to do that in the future #[unwind(aborts)] can just be allowed when specifying function pointers, that would be a backward compatible change

acfoltzer (Nov 07 2019 at 18:27, on Zulip):

hey folks, I'm going to be a bit late to the sync this week as we have a contractor at the house still

nikomatsakis (Nov 07 2019 at 18:33, on Zulip):

:wave:

nikomatsakis (Nov 07 2019 at 18:33, on Zulip):

Hey @WG-ffi-unwind -- quick sync? I'm not sure if anything happened this week, though

nikomatsakis (Nov 07 2019 at 18:34, on Zulip):

I would be happy to spend a bit of time now on looking over the hackmd

acfoltzer (Nov 07 2019 at 18:49, on Zulip):

okay, contractors just finished up. I could take a look at a hackmd—which one?

nikomatsakis (Nov 07 2019 at 18:51, on Zulip):

https://hackmd.io/ymsEL6OpR6OSMoFr1As1rw

nikomatsakis (Nov 07 2019 at 18:52, on Zulip):

I've not done anything, I got distracted by a million other pings :)

nikomatsakis (Nov 07 2019 at 18:52, on Zulip):

But I was saying last week that I felt like the organization wasn't right anymore

nikomatsakis (Nov 07 2019 at 18:52, on Zulip):

Let me take 10 minutes to see...

acfoltzer (Nov 07 2019 at 18:52, on Zulip):

gotcha, taking a look now. I likewise have been on other things for the last week, but we're getting close to the end of this demo sprint

acfoltzer (Nov 07 2019 at 18:53, on Zulip):

also the Cranelift PR for eh_frame data is active once again, so this is really going to be occupying my attention again soon

nikomatsakis (Nov 07 2019 at 18:54, on Zulip):

what I didn't like about this framing

nikomatsakis (Nov 07 2019 at 18:54, on Zulip):

for one thing I didnj't like the lsit of two options

nikomatsakis (Nov 07 2019 at 18:55, on Zulip):

I thnk i'd like to sort of collapse the list of arguments into broader "considerations"

nikomatsakis (Nov 07 2019 at 18:55, on Zulip):

I'm creating a second hackmd to play around

nikomatsakis (Nov 07 2019 at 18:58, on Zulip):

@Taylor Cramer -- you mentioned that Fuschia had some numbers regarding the cost of -Cpanic=abort vs -Cpanic=unwind somewhere?

nikomatsakis (Nov 07 2019 at 18:58, on Zulip):

I know that @gnzlbg had some smaller measurements

gnzlbg (Nov 07 2019 at 19:02, on Zulip):

I only had some synthetic examples, where the impact was massive, but it is hard to extrapolate from there to a real application. An App where ~0% of the code does C FFI calls won't probably see any differences, but an FFI wrapper might or might not see some, depending on other factors like whether it uses variables with destructors in the frames doing FFI calls, etc.

gnzlbg (Nov 07 2019 at 19:03, on Zulip):

Maybe it would be interesting to benchmark, e.g., mozjpeg or similar with -C panic=abort and -C panic=unwind.

nikomatsakis (Nov 07 2019 at 19:03, on Zulip):

I agree

Taylor Cramer (Nov 07 2019 at 19:04, on Zulip):

cc @tmandry who is the better person to talk with about fuchsia stuff going forwards

gnzlbg (Nov 07 2019 at 19:04, on Zulip):

It's a wrapper over mozjpeg-sys, so the impact there can be big, but if it turns out it is small, it is probably safe to conclude that this won't impact large apps except for maybe pathological cases

Taylor Cramer (Nov 07 2019 at 19:04, on Zulip):

and is the one who collected the most recent data on this

Taylor Cramer (Nov 07 2019 at 19:05, on Zulip):

We (fuchsia) also have a decently large amount of FFI, and so would probably be an interesting benchmark for this specific case as well

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

yes, it seems like a perfect case to measure

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

of course the cost of -Cpanic=unwind is greater than the cost would be to just have abort guards on FFI calls

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

but it's a good and easy to measure upper bound

nikomatsakis (Nov 07 2019 at 19:06, on Zulip):

(I think it's an upper bound?)

acfoltzer (Nov 07 2019 at 19:09, on Zulip):

the addendum in the first hackmd about nounwind fn foo() is really interesting; it hadn't occurred to me but of course makes a lot of sense that people would use a nounwind C ABI to implement targeted no-panic guarantees

Kyle Strand (Nov 07 2019 at 19:17, on Zulip):

Hey all, sorry I missed this sync session, and generally haven't been very helpful this week. @nikomatsakis let me know if you think it would be valuable for me to attend the lang meeting; I believe we don't have a real update since last meeting, though.

nikomatsakis (Nov 07 2019 at 19:19, on Zulip):

I think it's ok to say "no update, we're still working on preparing this core question"

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

I mean I also think this is a pretty important question to get right!

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

"the rest is details"

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

I think we've kind of covered the space

nikomatsakis (Nov 07 2019 at 19:20, on Zulip):

in terms of considerations

nikomatsakis (Nov 07 2019 at 19:29, on Zulip):

ok so I've been working on this alternate form

nikomatsakis (Nov 07 2019 at 19:30, on Zulip):

what I am trying to do is to factor out some of the "considerations" that are common, without getting into too much detail about specific approaches

nikomatsakis (Nov 07 2019 at 19:30, on Zulip):

what I wanted to do next is to create a section where I talk about the various options and try to explain their pros/cons in terms of those considerations

nikomatsakis (Nov 07 2019 at 19:30, on Zulip):

I'm running out of time to work on that :)

Kyle Strand (Nov 07 2019 at 19:46, on Zulip):

meaning of C == meaning of the "C" ABI specifier ?

Kyle Strand (Nov 07 2019 at 19:47, on Zulip):

I will try to spend some time looking at that in the next few days

nikomatsakis (Nov 14 2019 at 18:28, on Zulip):

I might be late and/or miss a meeting today, @WG-ffi-unwind

Kyle Strand (Nov 14 2019 at 18:44, on Zulip):

Shoot, I forgot this was right after the release team meeting.

Kyle Strand (Nov 14 2019 at 18:45, on Zulip):

Want to sync up now?

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

OK, I'm around now -- not sure that there is much to say

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

At this point I still really want to see some data

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

It looks like I've gotten "close" to implementing the changes needed, I have to incorporate what @Amanieu mentioned

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

And then probably bug @tmandry to find out how to replicate their numbers but with a local build?

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

Not sure how hard that will be

nikomatsakis (Nov 14 2019 at 18:47, on Zulip):

Or I guess it doesn't have to be me who does that

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

In fact it seems like it would be better if it were someone else :)

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

Ah one thing I did want to talk to you about @Kyle Strand was that I think we are ripe for an internals blog post

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

er, "Inside Rust"

nikomatsakis (Nov 14 2019 at 18:48, on Zulip):

Maybe introducing the group with a bit of background, talking about how the first big discussion has to do with "C", and encouraging people to check out the hackmd, come to the zulip channel, something like that?

Kyle Strand (Nov 14 2019 at 18:51, on Zulip):

"All areas of life progressively come to resemble TODO lists" - me, inside my head, often

Kyle Strand (Nov 14 2019 at 18:52, on Zulip):

That sounds good. I'm sorry I haven't been active here this week. I need to take some days off work and catch up on the rest of my life.

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

:/

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

Oh please never apologize for that :)

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

To be clear, I think we're making good progress

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

I feel like at this point we've really bottomed out the pros/cons around the extern "C" thing fairly deeply

nikomatsakis (Nov 14 2019 at 18:52, on Zulip):

We're missing some data and we need to kind of have a chat and try to "make a call"

Kyle Strand (Nov 14 2019 at 18:53, on Zulip):

My third sentence was intended to be merely informational, not a continuation of the apology :laughing:

nikomatsakis (Nov 14 2019 at 18:54, on Zulip):

Are you interested in trying to write said blog post?

Kyle Strand (Nov 14 2019 at 18:55, on Zulip):

Maybe - I think that a higher-priority use of my time, when I have some, would be to get our "summaries & current status" documents in a good state.

Kyle Strand (Nov 14 2019 at 18:55, on Zulip):

Especially if we hope to get new contributors to the discussion via this blog post

Kyle Strand (Nov 14 2019 at 18:56, on Zulip):

I agree about needing to have a chat to "make the call." I want to talk to Centril more about the "FFI is not a sandbox" point - he left a response in the HackMD saying the verbiage there was "not justified", but I'm still pretty convinced that it's a valid concern.

nikomatsakis (Nov 14 2019 at 18:56, on Zulip):

one thing -- we do now have the two documents

nikomatsakis (Nov 14 2019 at 18:56, on Zulip):

I would prefer to deprecate the first one :)

Kyle Strand (Nov 14 2019 at 18:57, on Zulip):

the two HackMDs?

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

at least two, but yeah

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

the one centril commented on is the older one

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

I'm curious if other people feel the second one is better :)

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

I don't have the "FFI is not a sandbox" thing in there

Kyle Strand (Nov 14 2019 at 18:57, on Zulip):

two documents about extern "C" considerations? Yes, at most one should be introduced to the master branch of the Repo.

nikomatsakis (Nov 14 2019 at 18:57, on Zulip):

at least not "explicitly", but I do have the

nikomatsakis (Nov 14 2019 at 18:58, on Zulip):

well I do have a section about exposing the "full" ABI

nikomatsakis (Nov 14 2019 at 18:58, on Zulip):

I think that quote could be added, potentially, though I'm not sure how imp't it is

nikomatsakis (Nov 14 2019 at 18:58, on Zulip):

Newer document: "meaning of the C abi"

Kyle Strand (Nov 14 2019 at 18:58, on Zulip):

I think the "sandbox" quote captures something important, but doesn't do so in a clear/unambiguous way (which makes sense because it's just a snippet from a personal email).

nikomatsakis (Nov 14 2019 at 18:59, on Zulip):

I think what could be improved in this doc a bit

nikomatsakis (Nov 14 2019 at 18:59, on Zulip):

hmm have to think about it

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

well what I find compelling in this structure is reading the options at the end

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

maybe I should move them to the front :)

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

and trying to tell different "stories"--

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

anyway

nikomatsakis (Nov 14 2019 at 19:00, on Zulip):

I haven't made up my mind yet, in any case

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

Though I am much more sympathetic to the "noexcept is an orthogonal consideration from ABI" POV that I thought I was

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

but I think it has to come paired with the more permissive defaults

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

i.e., if extern "C" fns make it UB to unwind by default

nikomatsakis (Nov 14 2019 at 19:01, on Zulip):

I think that combination is strictly worse than "C unwind" ABI

Kyle Strand (Nov 14 2019 at 19:04, on Zulip):

Though I am much more sympathetic to the "noexcept is an orthogonal consideration from ABI" POV that I thought I was

I think that at least partially captures the "FFI is not a sandbox" concern.

Kyle Strand (Nov 14 2019 at 19:04, on Zulip):

They're at least tightly coupled.

Kyle Strand (Nov 14 2019 at 19:04, on Zulip):

I absolutely agree that UB-by-default is strictly worse than not-UB-by-default.

Kyle Strand (Nov 14 2019 at 19:05, on Zulip):

And I think in that sense, making ABI boundaries have some "sandbox" qualities _is_ in line with Rust's goals and language-values.

Kyle Strand (Nov 14 2019 at 19:08, on Zulip):

Or, to remove the word "sandbox" entirely:

Kyle Strand (Nov 14 2019 at 19:09, on Zulip):

In any case, I think this is a reasonable TODO list for me, with a soft deadline of...let's say this time next week:

nikomatsakis (Nov 14 2019 at 19:11, on Zulip):

I think that at least partially captures the "FFI is not a sandbox" concern.

I agree

Kyle Strand (Nov 14 2019 at 19:11, on Zulip):

That's roughly in order of what I think my priorites ought to be.

nikomatsakis (Nov 14 2019 at 19:11, on Zulip):

I don't think I would waste a lot of time scraping zulip

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

but I do think that updating the repo is maybe good

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

in particular, our roadmap seems wrong

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

i.e., we have a "step 0" I thought was settled

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

but it seems is not

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

and we've not updated that

nikomatsakis (Nov 14 2019 at 19:12, on Zulip):

("figuring out the overall direction")

Kyle Strand (Nov 14 2019 at 19:18, on Zulip):

What I want to try to do vis-a-vis Zulip is maintain a document that we can point to such that anyone who reads it (whether they're newcomers or haven't visited the stream in a while) should feel equipped to participate in the conversation without needing to read too far back in Zulip history.

Kyle Strand (Nov 14 2019 at 19:18, on Zulip):

I think my original approach of "summarize each week's Zulip activity" may not be the most efficient way to do that, but I'd still like to find some way to accomplish the goal.

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

Yes.

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

I do think that's a super good goal

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

I guess what I'm contending .. hmm, what am I contending

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

One observation is that while I like the hackmd approach, I do often wish for a "go deeper" option

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

A wiki is a plausible structure here

nikomatsakis (Nov 14 2019 at 19:21, on Zulip):

(We could even use GH's wikis)

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

i.e., I'd like to start from "here are the proposals and some pros and cons"

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

and be able to click from a given pro to learn more about the thing in question

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

but I also feel a "woah diminishing returns" flag going on

Kyle Strand (Nov 14 2019 at 19:22, on Zulip):

Yes

Kyle Strand (Nov 14 2019 at 19:22, on Zulip):

Hmmm

nikomatsakis (Nov 14 2019 at 19:22, on Zulip):

lots of work to organize this information and not obviously worth the effort :)

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

though if we found a good structure, it might be less work overall

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

and I am deeply concerned about the way our current practices

Kyle Strand (Nov 14 2019 at 19:23, on Zulip):

Well, to be fair, the topics in the stream are decently well named, so anyone interested in the history of a given question can probably find what they want.

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

leave us with a very confusing "design trail"

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

I want to be able to come back to this decision in a year, two years, etc, and clearly lay out what we took into account

Kyle Strand (Nov 14 2019 at 19:23, on Zulip):

Yes!

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

Well, to be fair, the topics in the stream are decently well named, so anyone interested in the history of a given question can probably find what they want.

well I sort of imagine that

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

the wiki page would link to zulip topics

nikomatsakis (Nov 14 2019 at 19:23, on Zulip):

i.e., that's the "deepest"

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

so the wiki page might just be roughly what's in the current hackmd, but also have links to zulip topics where you can read more

Kyle Strand (Nov 14 2019 at 19:24, on Zulip):

Agreed. That's what I did in my first "summary" doc, but unfortunately that was probably the most time-consuming aspect

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

or rather, the "sections" of the current hackmd might each be a wiki page

Kyle Strand (Nov 14 2019 at 19:24, on Zulip):

Hm....it would be nice to be able to "tag" old Zulip messages.

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

well, you could just link to the topics in general

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

and not try to link to specific messages within

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

like "this was discussed here"

nikomatsakis (Nov 14 2019 at 19:24, on Zulip):

I'm imagining like

nikomatsakis (Nov 14 2019 at 19:25, on Zulip):

Interaction with -Cpanic=abort and UB

Today, the -Cpanic=abort feature works by changing panic!() to cause an immediate abort at the site of panic. This in turn means we can remove all the "landing pads" and thus remove the impact of unwinding completely.

However, if the source of the unwinding is foreign code that is not possible. Instead, if we wish to avoid UB, we have to add landing pads to the call sites of any foreign function that may unwind, such that we can abort when the unwinding enters into a Rust frame. Note that all designs include ways to indicate foreign functions that cannot unwind, though they vary in defaults and approach. Inserting these landing pads has a certain cost, though it is less than the full cost of -Cpanic=unwind (since in that case landing pads are required on all call sites, not just foreign call sites).

You might ask "why not just have it be UB to invoke a foreign function that unwinds with -Cpanic=abort?" The problem here is that then you can have libraries which compile under both modes but which produce UB when executed with -Cpanic=abort. If we install "abort guards", those same libraries would merely abort at runtime, which is much more noticeable.

If you come from C++, this might not seem like a big deal. After all, mixing -fexceptions code with code with -fno-exceptions code is going to mess everything up. But it's the kind of low-level footgun we'd prefer to avoid in Rust if we can.

Discussed on:

nikomatsakis (Nov 14 2019 at 19:25, on Zulip):

maybe that's a ton of work to keep up to date too :)

nikomatsakis (Nov 14 2019 at 19:26, on Zulip):

I want to be able to come back to this decision in a year, two years, etc, and clearly lay out what we took into account

also, to be clear, I think we're doing way better than ever before here

Kyle Strand (Nov 14 2019 at 19:28, on Zulip):

Agreed - when discussing my original RFCs, I found several old relevant GitHub threads quite late in the process

Kyle Strand (Nov 14 2019 at 19:44, on Zulip):

I think as a first pass, making that map from design questions to Zulip-topics is more important than writing new "summary" verbiage for each question.

Kyle Strand (Nov 14 2019 at 19:44, on Zulip):

The summarizing effort can then be done by anyone at any time

Kyle Strand (Nov 14 2019 at 19:44, on Zulip):

If indeed it's even necessary.

Kyle Strand (Nov 14 2019 at 19:48, on Zulip):

Anyway, for now I'll plan on following my "TODO" list above, with the caveat that I'll try to keep my time investment into "Zulip summary/links" docs minimal.

centril (Nov 14 2019 at 22:36, on Zulip):

@Kyle Strand "not justified" in the sense that a claim is being made like "this is the way it is" without the "why"

Kyle Strand (Nov 18 2019 at 00:08, on Zulip):

@nikomatsakis Here's my effort to remove the assumption that we'll move forward with "C unwind": https://github.com/rust-lang/project-ffi-unwind/pull/18

Kyle Strand (Nov 18 2019 at 01:43, on Zulip):

And here is my links-to-Zulip PR: https://github.com/rust-lang/project-ffi-unwind/pull/19

Kyle Strand (Nov 18 2019 at 01:49, on Zulip):

And one more: https://github.com/rust-lang/project-ffi-unwind/pull/20

Kyle Strand (Nov 18 2019 at 01:52, on Zulip):

I'm going to leave off w/ PRs for the time being. I am wondering if the project-planning document (with some modifications) could work as the primary "current status" document; what do you think?

nikomatsakis (Nov 18 2019 at 11:02, on Zulip):

the difference is basically whether to have the table or whether to have the list of checkboxes with specific ongoing tasks?

nikomatsakis (Nov 18 2019 at 11:02, on Zulip):

I think either could be fine

nikomatsakis (Nov 18 2019 at 11:03, on Zulip):

I merged rust-lang/project-ffi-unwind#18 but I think the others have conflicts, @Kyle Strand

Kyle Strand (Nov 19 2019 at 17:28, on Zulip):

the difference is basically whether to have the table or whether to have the list of checkboxes with specific ongoing tasks?

As I understood it, they're not really overlapping; the table is for project-scope, while the list is for immediate action items

Kyle Strand (Nov 19 2019 at 17:31, on Zulip):

@nikomatsakis thanks; the conflicts are resolved

acfoltzer (Nov 21 2019 at 17:48, on Zulip):

Hey folks, just a heads up that I have an appointment scheduled against our regular meeting time. Just to kick things off asynchronously:

nikomatsakis (Nov 21 2019 at 18:33, on Zulip):

@acfoltzer can you elaborate on the connection between malloc/free and unwinding?

Kyle Strand (Nov 21 2019 at 18:34, on Zulip):

@nikomatsakis I think you know my status already, but just to be explicit: I did do the "Zulip summary" task (my PRs), and I did have my conversation with Centril; I did not yet add anything to the "meaning of extern 'C'" doc, nor did I draft a blog post

nikomatsakis (Nov 21 2019 at 18:34, on Zulip):

Actually I don't know the status :)

nikomatsakis (Nov 21 2019 at 18:34, on Zulip):

I'm quite behind

nikomatsakis (Nov 21 2019 at 18:34, on Zulip):

BTW, I'll be away next week for vacation

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

But that all sounds pretty good, I guess we should merge some PRs?

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

In my view the single biggest remaining item is still to improve that branch I started and get some measurements?

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

I guess one question might be if there were any take-aways from conversation with @centril you can crystallize :)

nikomatsakis (Nov 21 2019 at 18:35, on Zulip):

or maybe it's in the PRs

centril (Nov 21 2019 at 18:36, on Zulip):

:wave: -- I think our conversation needs more participation from me

centril (Nov 21 2019 at 18:36, on Zulip):

(but I'm trying to cut down on my unread emails atm... :sweat_smile: )

Kyle Strand (Nov 21 2019 at 18:36, on Zulip):

In my view the single biggest remaining item is still to improve that branch I started and get some measurements?

The rustc branch?

Kyle Strand (Nov 21 2019 at 18:37, on Zulip):

I did not summarize the discussion w/ Centril in the PRs I've already submitted. I think the conversation was reasonably short & to the point, but I do still plan to write up a short summary

Kyle Strand (Nov 21 2019 at 18:37, on Zulip):

Maybe I can even do that today

nikomatsakis (Nov 21 2019 at 18:38, on Zulip):

The rustc branch?

confirm

nikomatsakis (Nov 21 2019 at 18:38, on Zulip):

One thing I could do is try to write out what steps are needed in my view

Kyle Strand (Nov 21 2019 at 18:38, on Zulip):

(but I'm trying to cut down on my unread emails atm... :sweat_smile: )

I sympathize greatly!

nikomatsakis (Nov 21 2019 at 18:39, on Zulip):

(I'm actually not entirely sure)

Kyle Strand (Nov 21 2019 at 18:40, on Zulip):

Do you intend your branch to be a possible prototype for an actual recommended rustc change (i.e. as part of a future PR)? Or is it just for measuring?

nikomatsakis (Nov 21 2019 at 18:42, on Zulip):

sorry, scarfing down a hasty lunch

nikomatsakis (Nov 21 2019 at 18:42, on Zulip):

uh, I think it would be both, but I'm more interested in the measurement

nikomatsakis (Nov 21 2019 at 18:43, on Zulip):

anyway th eonly work that's left, I think, is to tweak which fns get which attributes

nikomatsakis (Nov 21 2019 at 18:45, on Zulip):

I would like to see an actual execution where a throw from C++ gets intercepted :)

nikomatsakis (Nov 21 2019 at 18:45, on Zulip):

though I guess that this means adding some attributes which can be used to figure out how to unwind

nikomatsakis (Nov 21 2019 at 18:45, on Zulip):

and given that the only purpose to unwinding is so we can abort..

nikomatsakis (Nov 21 2019 at 18:46, on Zulip):

I'm not sure if those attributes actually make that much sense? I guess it depends on the platform, too

Kyle Strand (Nov 21 2019 at 18:46, on Zulip):

"how" to unwind?

Kyle Strand (Nov 21 2019 at 18:48, on Zulip):

Maybe I need to just take a look at the branch

nikomatsakis (Nov 21 2019 at 18:48, on Zulip):

yes, specifically the uwtable attribute

nikomatsakis (Nov 21 2019 at 18:48, on Zulip):

anyway maybe I'll open an issue and leave some notes

nikomatsakis (Nov 21 2019 at 18:48, on Zulip):

I could imagine trying to recruit someone to push on this

nikomatsakis (Nov 21 2019 at 18:49, on Zulip):

presuming none of us have the time

nikomatsakis (Nov 21 2019 at 18:49, on Zulip):

I guess I can open an issue on ... rust-lang/rust? maybe project-ffi-unwind? :)

Kyle Strand (Nov 21 2019 at 18:50, on Zulip):

project-ffi-unwind seems appropriate, though low-visibility...

Kyle Strand (Nov 21 2019 at 18:50, on Zulip):

though that may be alleviated by posting a blog post when I get around to drafting it

Kyle Strand (Nov 21 2019 at 18:54, on Zulip):

Niko, would you like to revise the open RFC to incorporate the changes to the "scope" verbiage, or should I?

acfoltzer (Nov 21 2019 at 21:43, on Zulip):

acfoltzer can you elaborate on the connection between malloc/free and unwinding?

sorry, I had to run shortly after writing this message; malloc and free are the primary use cases for callbacks into a Wasm guest from Rust code, which leave open the possibility that the guest callback could fault and leave Rust frames on the stack.

acfoltzer (Nov 21 2019 at 21:44, on Zulip):

specifically, suppose you want to copy a string into the Wasm linear memory from outside Wasm; you need to know where to put those bytes in memory. either the guest provides a pointer to a buffer and a maximum size, or you can call back into the guest's malloc, and use the pointer it gives back to you

acfoltzer (Nov 21 2019 at 21:46, on Zulip):

currently it's looking like we'll be doing the former approach for the first draft of the API, but the interface-types proposal uses malloc/free as part of the adapter expressions that are used to know how to move complex types between modules

acfoltzer (Nov 21 2019 at 21:47, on Zulip):

oh whoops, the quote feature doesn't ping; cc @nikomatsakis

acfoltzer (Dec 05 2019 at 18:32, on Zulip):

hey folks, no updates from me again this week; still heads down in building out our product. the outlook on our need for FFI unwinding remains the same as my last update: we won't need it in the short term due to some self-imposed restrictions on our use of Wasm, but will need it in the longer term to keep up with additional Wasm specs like interface-types

nikomatsakis (Dec 05 2019 at 18:34, on Zulip):

Hi all =) I didn't really do anything since last week either

Kyle Strand (Dec 05 2019 at 18:34, on Zulip):

I have been sick, plus the holidays, so no update here either :/

gnzlbg (Dec 05 2019 at 18:44, on Zulip):

I'm back from travelling

nikomatsakis (Dec 05 2019 at 18:55, on Zulip):

Sorry, got pulled into something -- I'd still like to get some "figures" on what impact these results have on code size.

nikomatsakis (Dec 05 2019 at 18:55, on Zulip):

I did not find time to write up any kind of instructions on what still needs to be done in that regard

nikomatsakis (Dec 05 2019 at 19:21, on Zulip):

(To that end, I've spent the last little bit trying to get a new desktop setup to build Rust :)

nikomatsakis (Dec 12 2019 at 18:41, on Zulip):

Hey @WG-ffi-unwind

nikomatsakis (Dec 12 2019 at 18:41, on Zulip):

So I've still not had time to do anything

nikomatsakis (Dec 12 2019 at 18:42, on Zulip):

But I did have an interesting chat with @Josh Triplett

nikomatsakis (Dec 12 2019 at 18:42, on Zulip):

I feel like we need to organize a meeting to have an in-depth chat with lang team; maybe we should schedule it for very early January or something

nikomatsakis (Dec 12 2019 at 18:42, on Zulip):

and give ourselves a deadline to get data or just make the decision without data

nikomatsakis (Dec 12 2019 at 18:43, on Zulip):

The main thing I got from my chat with @Josh Triplett was that one use case we should be sure we are able to accommodate is the case where it is UB to unwind and hence we have zero extract overhead. I think that if we declared that "C" can unwind, the way we would accommodate that is by having every extern "C" fn declared with #[unwind(never)] or some such annotation.

nikomatsakis (Dec 12 2019 at 18:43, on Zulip):

This might suffice, @Josh Triplett was thinking primarily of cases where people are literally counting bytes, which I imagine can afford a bit of extra annotation, but it's still worth thinking about.

nikomatsakis (Dec 12 2019 at 18:44, on Zulip):

Or maybe there wants to be a -Cpanic=ub flag =)

nikomatsakis (Dec 12 2019 at 18:44, on Zulip):

Or of course the C+unwind design

Kyle Strand (Dec 12 2019 at 18:45, on Zulip):

Sorry, no update from me again. I do want to circle back on RFC #2797, the one announcing the project group, and see if we can get it merged soon.

acfoltzer (Dec 12 2019 at 18:45, on Zulip):

sorry to be late, I'm at the Bytecode Alliance meeting (with Josh, incidentally)

Kyle Strand (Dec 12 2019 at 18:49, on Zulip):

By "he case where it is UB to unwind", do you mean where the user _wants_ it to be UB, or where it's undefined for some other reason?

nikomatsakis (Dec 12 2019 at 18:50, on Zulip):

Sorry, no update from me again. I do want to circle back on RFC #2797, the one announcing the project group, and see if we can get it merged soon.

oh geez :)

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

By "the case where it is UB to unwind", do you mean where the user _wants_ it to be UB, or where it's undefined for some other reason?

I mean where the user wants it to be UB, because they want the compiler to optimize everything away

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

in particular, they do not want the "shim" that aborts, no matter how small it is

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

My belief (yet to be verified with data) is that such a shim will be negligible for the vast majority of use cases

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

@Josh Triplett's point is that there will always be cases for which no increase is acceptable, and we should be able to accommodate that

nikomatsakis (Dec 12 2019 at 18:51, on Zulip):

I think that sounds correct, but I also suspect that some add'l effort is ok in such cases

Kyle Strand (Dec 12 2019 at 18:53, on Zulip):

I think giving users the _ability_ to avoid such shims makes the cost less important. In general, this is a cost that the "systems programming" world has already opted into; the idea is that exceptions are "zero cost unless they're actually used".

nikomatsakis (Dec 12 2019 at 19:05, on Zulip):

@Kyle Strand I think the ergonomics and defaults matter a lot there

nikomatsakis (Dec 12 2019 at 19:06, on Zulip):

I think it's a design failure if people start adding #[unwinds(never)] annotations reflexively because of a concern about cost

nikomatsakis (Dec 12 2019 at 19:07, on Zulip):

but if people do it because they're literally counting bytes, seems ok

nikomatsakis (Dec 12 2019 at 19:09, on Zulip):

I'm not sure where e.g. fuchsia would fall on such a spectrum

nikomatsakis (Dec 12 2019 at 19:09, on Zulip):

anyway I think we should set ourselves some kind of deadline :)

Kyle Strand (Dec 12 2019 at 19:14, on Zulip):

I think we're in agreement, but I also think the broader "systems programming ecosystem" seems to consider landing pads "zero cost" already anyway. (E.g. C++ people will say "exceptions are zero-cost until you actually throw them.") So I think the risk of people adding unwinds(never) by default is low.

Kyle Strand (Dec 12 2019 at 19:15, on Zulip):

As for a deadline... I'm slightly concerned that without #2797 being merged, i.e., without a formal announcement of the project group, people will feel that they didn't have an opportunity to participate, which I get the sense is something you're trying to improve across the Rust project.

Kyle Strand (Dec 12 2019 at 19:17, on Zulip):

So I am tempted to say we can't set a deadline until, say, a week after formally announcing the group; that way, if new voices chime in, we can take that into account.

nikomatsakis (Dec 12 2019 at 19:17, on Zulip):

Interesting. Well, that's just busy work. I can try to do it soon

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

I hadn't considered that people might not realize discussion was active

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

In any case I think we will want to write up a good blog post

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

That summaries the arguments

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

It'd be a good idea to do that before the meeting is scheduled

Kyle Strand (Dec 12 2019 at 19:18, on Zulip):

Yes

nikomatsakis (Dec 12 2019 at 19:18, on Zulip):

so that people can start to react and we can take some of that into account during lang team discussion

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

(I guess I can try to update some of the language based on the comment threads, too)

Kyle Strand (Dec 12 2019 at 19:20, on Zulip):

Hm, let's try to have blog ready to post and RFC merged by this time next week, then the first week of January schedule a meeting w/ Lang team

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

mm I'm not sure if that's realistic :)

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

it might be

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

I also still think data would be really, really great

Kyle Strand (Dec 12 2019 at 19:20, on Zulip):

I think the RFC is close and I can work on the blog post

nikomatsakis (Dec 12 2019 at 19:20, on Zulip):

This conversion will be much more informed if we can say 1% overhead or something like that

Kyle Strand (Dec 12 2019 at 19:20, on Zulip):

Do you think that needs to be in the blog post?

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

I think it would be better, yes

Kyle Strand (Dec 12 2019 at 19:21, on Zulip):

(By "the RFC" I just mean the announcement one that's already open)

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

Yes, I understood

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

it probably just takes a few hours of focus to get data

nikomatsakis (Dec 12 2019 at 19:21, on Zulip):

/me ponders

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

I got stuck the lsat time because my desktop was dead

Kyle Strand (Dec 12 2019 at 19:22, on Zulip):

Okay. Is that few hours mostly for getting your fork of rustc into a state for taking the metrics?

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

but I've got an updated one up and going now :)

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

Okay. Is that few hours mostly for getting your fork of rustc into a state for taking the metrics?

yeah

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

I may be underestimating of course

nikomatsakis (Dec 12 2019 at 19:22, on Zulip):

but I think it's close

Kyle Strand (Dec 12 2019 at 19:22, on Zulip):

Hm, maybe this is a good time for me to dive in and try to help with that.

Kyle Strand (Dec 12 2019 at 19:25, on Zulip):

Well, I think we can get the announcement RFC merged, anyway, and I can start drafting a blog post with <TODO> placeholder for when some data is available.

Kyle Strand (Dec 12 2019 at 19:29, on Zulip):

Can you expand a bit on why the initial blog post should have data? Your original description sounded more like an announcement and invitation-to-participate; if that's the goal, I think making a note that we could use some help w/ the data-collection effort would actually be better than a final result from that effort.

nikomatsakis (Dec 12 2019 at 19:32, on Zulip):

I guess it depends

nikomatsakis (Dec 12 2019 at 19:32, on Zulip):

I don't think data is required

nikomatsakis (Dec 12 2019 at 19:32, on Zulip):

Maybe not worth blocking on

nikomatsakis (Dec 12 2019 at 19:33, on Zulip):

I'm basically concerned about knee-jerk reactions

Kyle Strand (Dec 12 2019 at 19:33, on Zulip):

True....

Kyle Strand (Dec 12 2019 at 19:34, on Zulip):

Well, I'll try to be more available this week, and I'll start w/ getting the RFC comments addressed

nikomatsakis (Dec 12 2019 at 19:34, on Zulip):

but I think if we leave a placeholder like "we really want to measure this" it is also fine

Kyle Strand (Dec 13 2019 at 02:06, on Zulip):

(deleted)

Kyle Strand (Dec 17 2019 at 21:46, on Zulip):

I had some family health issues come up and will not have as much time as I thought I would this week.

Kyle Strand (Dec 19 2019 at 18:35, on Zulip):

Hey @nikomatsakis, @acfoltzer - nothing to report. I should have time to draft a blog post next week, since I'll be on leave for the holidays. Shall we plan to reconvene next year, on the 2nd?

nikomatsakis (Dec 19 2019 at 18:41, on Zulip):

Hey @Kyle Strand -- running slow today myself

nikomatsakis (Dec 19 2019 at 18:41, on Zulip):

I think reconvening makes sense. My main next step -- which I'll do right now -- was going to be e-mailing to the lang team to make another effort to organize a time for in-depth disussion (both of this but also other topics)

nikomatsakis (Dec 19 2019 at 18:42, on Zulip):

I feel like I've about given up on an attempt to gather data. I suppose I could try to measure the size of Fuchsia with my existing branch, as it's probably "pretty close" to what the cost would be.. maybe an upper bound, even.

nikomatsakis (Dec 19 2019 at 18:43, on Zulip):

To that end, @tmandry, how hard would it be for me to measure the size of a Fuchsia binary?

nikomatsakis (Dec 19 2019 at 18:49, on Zulip):

(Whatever it was that you measured to get that 10% "binary size" figure)

tmandry (Dec 19 2019 at 19:26, on Zulip):

@nikomatsakis I can measure one thing if you want, or I can point you to instructions to building a rust toolchain for fuchsia + building fuchsia with it

nikomatsakis (Dec 19 2019 at 19:26, on Zulip):

@tmandry is it a pain to build with a custom rust toolchain? I basically wanted to do a build with this branch I made.

tmandry (Dec 19 2019 at 19:27, on Zulip):

well, it's just something that I think I still need to document ;)

tmandry (Dec 19 2019 at 19:27, on Zulip):

it's not a huge pain, though

tmandry (Dec 19 2019 at 19:28, on Zulip):

I'll throw some notes in a doc

tmandry (Dec 20 2019 at 00:15, on Zulip):

@nikomatsakis sent you an email, feel free to share any of it

tmandry (Dec 20 2019 at 00:15, on Zulip):

(sorry, I should document it in a more public place, but leaving tomorrow)

Kyle Strand (Jan 02 2020 at 18:31, on Zulip):

@nikomatsakis @acfoltzer Nothing much to report. I have started drafting a blog post, for which I've posted a link in #project-ffi-unwind > Blog post .

nikomatsakis (Jan 02 2020 at 18:39, on Zulip):

Hi :)

nikomatsakis (Jan 02 2020 at 18:40, on Zulip):

I was going to spend some time going over blog post and giving feedback

Kyle Strand (Jan 02 2020 at 18:40, on Zulip):

Sounds reasonable.

nikomatsakis (Jan 02 2020 at 18:40, on Zulip):

Do you have outstanding edits, @Kyle Strand ?

nikomatsakis (Jan 02 2020 at 18:41, on Zulip):

I guess the other thing is to schedule a time to chat w/ lang team

nikomatsakis (Jan 02 2020 at 18:41, on Zulip):

We've now created a Monday "in depth meeting slot"

nikomatsakis (Jan 02 2020 at 18:41, on Zulip):

Does Monday at noon EST work for folks? (cc @acfoltzer) -- I should create a doodle to find a good week

Kyle Strand (Jan 02 2020 at 18:42, on Zulip):

I don't have unpushed changes or anything, but the draft isn't complete

nikomatsakis (Jan 02 2020 at 18:42, on Zulip):

in particular I was thining I might make edits

Kyle Strand (Jan 02 2020 at 18:42, on Zulip):

noon EST Monday is okay.

Kyle Strand (Jan 02 2020 at 18:42, on Zulip):

Pushing edits to my branch would be fine.

Kyle Strand (Jan 02 2020 at 18:43, on Zulip):

I've just made you a collaborator on my fork

nikomatsakis (Jan 02 2020 at 18:44, on Zulip):

ok

nikomatsakis (Jan 09 2020 at 18:33, on Zulip):

Hi @WG-ffi-unwind -- so -- I was thinking

nikomatsakis (Jan 09 2020 at 18:34, on Zulip):

I've been wanting to schedule a lang team design meeting to present the details of "C" vs "C unwind" etc

nikomatsakis (Jan 09 2020 at 18:34, on Zulip):

it seems to be surprisingly hard for us to prepare a concise summary though :) (complex ..)

nikomatsakis (Jan 09 2020 at 18:35, on Zulip):

anyway I am wondering if it might hep to schedule like a 1 or 2h block to try to organize the information or plan ahead? not sure what's best.

nikomatsakis (Jan 09 2020 at 18:35, on Zulip):

(also, sync time :)

Kyle Strand (Jan 09 2020 at 18:42, on Zulip):

That sounds reasonable to me.

nikomatsakis (Jan 09 2020 at 18:53, on Zulip):

I guess the trick is to find a time =)

Kyle Strand (Jan 09 2020 at 19:03, on Zulip):

I am pretty flexible and can generally make time when others are available.

nikomatsakis (Jan 09 2020 at 19:28, on Zulip):

some time next week then? I can setup a doodle I guess

nikomatsakis (Jan 09 2020 at 19:28, on Zulip):

or maybe you can @Kyle Strand, if you have a moment

nikomatsakis (Jan 09 2020 at 19:28, on Zulip):

I do thnk it's worth allocating maybe even 2h for this

nikomatsakis (Jan 09 2020 at 19:29, on Zulip):

I also think it should be a relatively small group perhaps -- like you and I could just do it

Kyle Strand (Jan 09 2020 at 19:31, on Zulip):

Okay. Should I exclude weekends?

nikomatsakis (Jan 09 2020 at 20:00, on Zulip):

yes :)

acfoltzer (Jan 09 2020 at 22:05, on Zulip):

hey folks, sorry I've missed the last few check-ins. vacation + big beginning of year planning meetings. I will be available next week for a meeting to feed into the lang team design

nikomatsakis (Jan 09 2020 at 22:25, on Zulip):

oh, that'd be good

nikomatsakis (Jan 09 2020 at 22:26, on Zulip):

the hope @acfoltzer is that we will schedule a sync w/ team on monday Jan 20 at noon Boston time

nikomatsakis (Jan 09 2020 at 22:26, on Zulip):

@Kyle Strand (you're making doodle for next week?)

acfoltzer (Jan 09 2020 at 22:31, on Zulip):

ah, Jan 20 is a holiday for me but I'd be able to make it

Kyle Strand (Jan 10 2020 at 00:05, on Zulip):

Yes, making the doodle now

Kyle Strand (Jan 10 2020 at 00:08, on Zulip):

Are there any other blocks of time we can immediately veto? What's the latest people can go?

Kyle Strand (Jan 10 2020 at 00:09, on Zulip):

Currently I'm just filling in every two-hour block starting on every half-hour from 9:30am MST to 6pm (ending at 8pm) on every day of the week except where I have meetings

Kyle Strand (Jan 10 2020 at 00:13, on Zulip):

And also leaving out the lang team and compiler team meeting times

Kyle Strand (Jan 10 2020 at 00:16, on Zulip):

'kay, here 'tis: https://doodle.com/poll/x4c9xquauteew7gn

Kyle Strand (Jan 10 2020 at 20:30, on Zulip):

@WG-ffi-unwind

acfoltzer (Jan 10 2020 at 21:25, on Zulip):

done; thanks for the ping!

nikomatsakis (Jan 10 2020 at 23:43, on Zulip):

whoosh, that was a very fine-grained poll :) looks like monday afternoon is maybe best...

Kyle Strand (Jan 12 2020 at 19:24, on Zulip):

@Amanieu and @gnzlbg , do you want to participate in the meeting discussed above, and if so, would 6:30 am UTC work for you?

Kyle Strand (Jan 12 2020 at 19:24, on Zulip):

If that time doesn't work, please let us know and fill out the Doodle poll

Amanieu (Jan 12 2020 at 19:28, on Zulip):

I've updated the doodle.

Amanieu (Jan 12 2020 at 19:29, on Zulip):

Monday evening is looking good

gnzlbg (Jan 12 2020 at 19:44, on Zulip):

I've updated the doodle as well

Kyle Strand (Jan 12 2020 at 20:18, on Zulip):

Thanks for the quick response! 6am UTC tomorrow it is.

Kyle Strand (Jan 12 2020 at 20:20, on Zulip):

I've sent an invite to Niko, but I don't seem to have the rest of you in my email contacts list.

Amanieu (Jan 12 2020 at 20:25, on Zulip):

amanieu@gmail.com

Amanieu (Jan 12 2020 at 20:26, on Zulip):

Also, the selected time on doodle is 8pm UTC. Not sure where you got 6am from?

Kyle Strand (Jan 13 2020 at 05:24, on Zulip):

I was adding instead of subtracting to get UTC from my local time. Oops.

gnzlbg (Jan 13 2020 at 17:16, on Zulip):

I have a meeting 1:30h before this one, and it appears to be of unbounded length. I'll try to make it, but I'm not sure if it will work

nikomatsakis (Jan 13 2020 at 18:36, on Zulip):

BTW I don't think the lang-team design meeting will happen until Feb due to MLK Jr Day here in the US

nikomatsakis (Jan 13 2020 at 18:36, on Zulip):

but I still think we should try to get this done

acfoltzer (Jan 16 2020 at 18:29, on Zulip):

Hey folks, I don't really have anything to add since our call. Still pretty underwater working on our product, but unwinding support is making its way into cranelift

Kyle Strand (Jan 16 2020 at 18:34, on Zulip):

I also have nothing to add since our call. I have not had time yet to translate our thoughts Monday into a blog post.

Kyle Strand (Jan 16 2020 at 18:36, on Zulip):

Tangent about cranelift: @nikomatsakis do you have any insight into Cranelift's future? My impression was that (1) Cranelift was primarily supported by Mozilla, and (2) the recent layoffs affected the Cranelift team pretty hard.

nikomatsakis (Jan 16 2020 at 18:36, on Zulip):

I am aware of one layoff from within Cranelift, but there may be more

nikomatsakis (Jan 16 2020 at 18:37, on Zulip):

I don't know more than you do I don't think

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

the main thing I had hoped to touch base on here was who was going to try and translate the stuff from our call into a blog post :)

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

is that you, @Kyle Strand ?

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

I think it's a good idea to produce a document that avoids too much background -- think of the lang team as audience

Kyle Strand (Jan 16 2020 at 18:38, on Zulip):

The spirit is willing but the flesh is time-constrained

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

I think a explainer with background is probably also good but separately :)

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

lol fair

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

I had a few other thoughts after our call

nikomatsakis (Jan 16 2020 at 18:38, on Zulip):

one thing I was thinking of

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

is that I feel like we have a large number of desiderata

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

that we often failed to remember

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

e.g., "can insert a shim into extern C fn" or something

nikomatsakis (Jan 16 2020 at 18:39, on Zulip):

maybe a table would make sense

Kyle Strand (Jan 16 2020 at 18:39, on Zulip):

Since the explainer is basically done, maybe I should just post that separately? On its own, it doesn't really seem like useful content for the Internals blog, and unfortunately I don't have a personal blog myself yet, but it seems like it would be useful to put out there in the world somewhere.

Kyle Strand (Jan 16 2020 at 18:40, on Zulip):

Function pointers seem like an oft-neglected consideration

Kyle Strand (Jan 16 2020 at 18:40, on Zulip):

Despite the fact that we're all aware of the complications therein, having previously discussed them!

acfoltzer (Jan 16 2020 at 18:41, on Zulip):

I can help with an editing pass and other feedback but unfortunately my time is extremely constrained

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

Re: explainer:

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

I'm not 100% sure what that refers to :)

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

background material?

nikomatsakis (Jan 16 2020 at 18:41, on Zulip):

if so, maybe push to the repo and then write a blog post announcing it exists

nikomatsakis (Jan 16 2020 at 18:42, on Zulip):

I think people would be interested

Kyle Strand (Jan 16 2020 at 18:43, on Zulip):

I mean the majority of my original draft in that one PR: https://github.com/BatmanAoD/project-ffi-unwind/blob/BlogPost-announcement/blogposts/inside-rust/01-announcement.md

nikomatsakis (Jan 16 2020 at 18:43, on Zulip):

yeah that's what I figured you meant

nikomatsakis (Jan 16 2020 at 18:43, on Zulip):

seems great

Kyle Strand (Jan 16 2020 at 18:44, on Zulip):

I'll move the "should the "C" ABI permit unwinding" section to the bottom and re-cast it as a "preview" of a more in-depth summary of the project group's (PG's?) discussions so far.

nikomatsakis (Jan 16 2020 at 18:45, on Zulip):

+1

nikomatsakis (Jan 16 2020 at 18:45, on Zulip):

I might try my hand at making this table I was talking about

nikomatsakis (Jan 16 2020 at 18:45, on Zulip):

oh and

nikomatsakis (Jan 16 2020 at 18:46, on Zulip):

I plan to schedule a lang team meeting sometime in Feb -- it'll be a design meeting, so monday at noon Eastern time

nikomatsakis (Jan 16 2020 at 18:46, on Zulip):

do y'all have any preferences when it comes to weeks?

Kyle Strand (Jan 16 2020 at 18:46, on Zulip):

Okay. I have no time today but maybe some tomorrow, definitely this weekend, and Monday is a day off for me so... hopefully I'll make some progress on both this and job-search-stuff

nikomatsakis (Jan 16 2020 at 18:46, on Zulip):

I can make a doodle if needed :)

Kyle Strand (Jan 16 2020 at 18:47, on Zulip):

Looks like I have no prior commitments on any Monday in February.

nikomatsakis (Jan 16 2020 at 18:49, on Zulip):

I plan to schedule a lang team meeting sometime in Feb -- it'll be a design meeting, so monday at noon Eastern time

@acfoltzer you seem more likely to have conflicts...

acfoltzer (Jan 16 2020 at 18:49, on Zulip):

the week of the 10th I'm in the bay area for a bunch of wasm meetings

acfoltzer (Jan 16 2020 at 18:50, on Zulip):

as far as other times go, it's less about having specific conflicts on my calendar, and more about overall number of hours I can devote to non-product things

nikomatsakis (Jan 16 2020 at 18:51, on Zulip):

I don't feel you have to attend

acfoltzer (Jan 16 2020 at 18:51, on Zulip):

which is to say, other than the 10th all of my Mondays are pretty much free

nikomatsakis (Jan 16 2020 at 18:51, on Zulip):

I guess @Amanieu your schedule would be pretty relevant too

Amanieu (Jan 16 2020 at 18:51, on Zulip):

I'm away on a ski trip for the 1st week of Feb

acfoltzer (Jan 16 2020 at 18:51, on Zulip):

I would like to, because having a concrete commitment helps me actually prioritize paying attention to this issue despite our product managers :pray:

Amanieu (Jan 16 2020 at 18:52, on Zulip):

But after that it should be fine

nikomatsakis (Jan 16 2020 at 18:57, on Zulip):

I am reminded that I will be on vacation Feb 17

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

So that means:

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

heh

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

seems far away

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

but then...

Amanieu (Jan 16 2020 at 18:58, on Zulip):

Unless we can fit it in late Jan?

nikomatsakis (Jan 16 2020 at 18:58, on Zulip):

I'm not avail next 2 weeks

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

I guess maybe next week

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

it's a holiday :)

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

but ..

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

my partner would kill me :P

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

could shoot for another day of the week, it's just that it's hard to find those

Amanieu (Jan 16 2020 at 18:59, on Zulip):

Let's not then. A dead niko is an unproductive niko.

nikomatsakis (Jan 16 2020 at 18:59, on Zulip):

scheduling is hard :)

Kyle Strand (Jan 16 2020 at 18:59, on Zulip):

@acfoltzer any chance of trying to schedule this between your wasm meetings?

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

let's do this: try to write it up asap,

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

plan to talk feb 24, but see if we can find an earlier time, and/or conduct the discussion async

Kyle Strand (Jan 16 2020 at 19:00, on Zulip):

Conduct the discussion w/ the lang team async?

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

yeah, maybe hopeless tho

Kyle Strand (Jan 16 2020 at 19:00, on Zulip):

(I thought that was what we were scheduling for Feb)

nikomatsakis (Jan 16 2020 at 19:00, on Zulip):

it is:)

Kyle Strand (Jan 16 2020 at 19:00, on Zulip):

mm

nikomatsakis (Jan 16 2020 at 19:01, on Zulip):

I'm mostly thiking that the solution to "Scheduling hell" is async, but it only sometimes works

Kyle Strand (Jan 16 2020 at 19:01, on Zulip):

Well, to be fair, I wasn't really hoping for _consensus_ among the team from one meeting, necessarily.

nikomatsakis (Jan 16 2020 at 19:01, on Zulip):

I definitely think it'd be better if we can start the conversation earlier

nikomatsakis (Jan 16 2020 at 19:01, on Zulip):

regardless

Kyle Strand (Jan 16 2020 at 19:01, on Zulip):

But I think if we start the discussion async, then it's probably not crucial that all four of us be available for the sync lang team discussion

Kyle Strand (Jan 16 2020 at 19:01, on Zulip):

team_meeting.await

Kyle Strand (Jan 16 2020 at 19:04, on Zulip):

All right, I'm heading to lunch now. Sounds like we have, as usual, just enough of a plan to start heading in the right general direction :)

acfoltzer (Jan 16 2020 at 19:05, on Zulip):

acfoltzer any chance of trying to schedule this between your wasm meetings?

sorry, had to step away for a moment. I am at the wasm summit at Google all day on the 10th, but I don't know yet what the agenda is

acfoltzer (Jan 16 2020 at 19:05, on Zulip):

generally speaking though if the 10th works for everyone else, y'all should go for it. my motivations for being there are, as described above, mostly selfish

Kyle Strand (Jan 23 2020 at 17:41, on Zulip):

@WG-ffi-unwind Sorry all, I didn't actually make any headway on anything this week.

acfoltzer (Jan 23 2020 at 18:31, on Zulip):

same, at least in terms of direct work on this project. It looks like I'm going to be able to make it to the Rust All-Hands, which will coincidentally give me a good amount of airplane time where I hopefully be temporarily free of product concerns

acfoltzer (Jan 23 2020 at 18:31, on Zulip):

and, of course, the opportunity for high-bandwidth collaboration with anyone else on the team who will be there :slight_smile:

nikomatsakis (Jan 23 2020 at 18:39, on Zulip):

:wave: been busy, I didn't get too far either :)

nikomatsakis (Jan 23 2020 at 18:39, on Zulip):

sorry, had a call come up this week, too

nikomatsakis (Jan 23 2020 at 18:39, on Zulip):

meant to ping earlier but ..

Kyle Strand (Jan 23 2020 at 18:41, on Zulip):

I will also be at the Rust All-Hands! In fact, it will be my first time _ever_ outside the states, something I've looked forward to for...well, since I was a kid.

acfoltzer (Jan 23 2020 at 18:42, on Zulip):

oh wow, that's so exciting!

acfoltzer (Jan 23 2020 at 18:42, on Zulip):

looking forward to meeting you :)

Kyle Strand (Jan 23 2020 at 18:51, on Zulip):

Same!

Last update: Jan 28 2020 at 01:55UTC