ffi: different input and output types for tasks

[jsha]

When documenting the FFI API (#3424), one thing I found confusing is that the *hyper_task type has two different purposes:

1. It can be added to an executor to be polled.
2. Eventually it will be returned from hyper_executor_poll.

For (2), it will have a type and a value. For (1), it won't yet have a value. Will it have a type?

For (2), is it possible to put the same task back into the executor? I think the answer is no.

I think it would be clearer to split this into two types: *hyper_task, and *hyper_task_result, corresponding to (1) and (2) respectively.

[seanmonstar]

Hm, I see what you mean. Separating the types would make the distinction even clearer.

Is it worth it? It does seem like it'd require an extra allocation for every task, to box up the result separately.

Some other examples that I think of are like getting a CURL*, and then passing it to perform(), and then afterwards it has extra stuff in it.

[jsha]

It doesn't require an extra Box. You can just define an opaque struct and cast the return value to a pointer of that type. From the Rust perspective, *hyper_task would be the same type as *hyper_task_result, but from the C API they would be different. The opaque struct would exist solely from the perspective of the C API and wouldn't have Rust implementations.