With the default impl, if I call `self.a.poll_drop` and then `self.b.poll_drop` and b wasn't ready, a will have been dropped in place, no?
-
-
-
You can’t call poll_drop, just like you can’t call drop.
- Još 2 druga odgovora
Novi razgovor -
-
-
Great post! I'm excited that this problem is being worked on. As a tweak, did you consider `poll_drop_ready` instead of `poll_drop`? The contract would be that `poll_drop_ready` gets the value into a droppable state but not do the drop.
-
The way you drop async objects would be to first call `poll_drop_ready` until `Ready`, *then* call regular drop. In non-async contexts, you could call `drop` directly and the async drop impl would handle that case by spawning a cleanup task or erroring?
- Još 4 druga odgovora
Novi razgovor -
-
- Kraj razgovora
Novi razgovor -
-
This is super cool! I remember when
@Brittain_Ben asked for `trait AsyncDrop` I pointed out that the problem is isomorphic to the problem of linear types (the same solution works but we don't want to do that), but an optional poll_drop function is a nice way out!Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
-
-
Love this! I've been using a workaround, having my executor set a thread-local `mpsc::Sender<Box<dyn Future+Send>>` which is drained by a "async cleanup thread." The `Drop` implementation sends its task into the queue. This proposal would improve my life.
Hvala. Twitter će to iskoristiti za poboljšanje vaše vremenske crte. PoništiPoništi
-
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.