What should the spawned function's type be?

[abrown]

The thread.spawn instruction is currently defined to invoke a very constrained shared function type: [i32] -> []. This section explains some of the motivation for these constraints, but other opinions are valuable here. What should the spawned function's type be?

[conrad-watt]

I don't think there's be much harm in having a less-constrained input type, but this seems fine for an MVP.

[rossberg]

Without closures, not being able to pass any arguments to the function is a severe limitation that would require jumping through hoops of global state again in many cases. I think we should definitely allow spawn to take arguments and pass them to the function.

I agree that it doesn't need results, however.

[rossberg]

You can of course do pretty much everything with global state. That doesn't mean you should have to. Global state tends to be error-prone and costly, and it is best avoided where possible, in particular in the presence of concurrency. I think our design should support that, especially where it doesn't cost anything. Arguments are an easy way to avoid it for passing information to subtasks, which is a very common case, I'd assume.

Closures would allow to pre-apply the arguments to the function that is spawned, which is how some languages do it (or having to define class instances as "runners" is a heavyweight way of doing the same thing). But short of that feature, spawn itself is the only point where custom arguments can be supplied.

[fitzgen]

Passing a single i32 to the spawned function seems reasonable to me. That can be the closure pointer, avoiding the need to stuff it in some global state somewhere. (And the global state itself would need to be protected in the face of concurrent thread.spawns; seems easier and more convenient to pass an i32 through.)

[rossberg]

User-space closure pointer = temporary global state, right? Which then generally requires (thread-safe) dynamic memory management, in the case of i32 in linear memory (edit: or a table). Which would be rather backwards to a runtime e.g. targeting the GC proposal.

Is there any advantage in depriving thread.spawn of more general parameters?

[fitzgen]

I was arguing in favor of adding a single i32 as a compromise (vs no parameters at all), but if there is appetite for more general arguments, then that also seems good to me barring any reason why that becomes difficult.

[abrown]

Ok, I opened up #15 to loosen this restriction.

[yamt]

i'd suggest to make it take any function parameters as call_indirect/call does.

[cfallin]

Taking the analogy further: if one day there is a join primitive, it ought to return multiple values from the entry-function return or thread-exit operator, the same way that a call can return multiple values. This gives a nice property for code transforms: parallelizing a function call (forking it into the background) can be done with direct operator replacement, and no indirection is required.