`futures` integration about parking_lot HOT 10 CLOSED

@Amanieu

I've played a bit around with this here (only mutex so far), but I'm running into a pretty interesting issue: I cannot rely on looping try_lock, because they're not guaranteed to fall so they are available at some point when fetched.

I think a possible solution is to make use of another flag in mutexes, which essentially says "you can't someone else is currently using this mutex, so you cannot directly acquire it after it is unlocked", but even that seems pretty messy.

What I'm thinking is some method that called in Mutex::async_lock() to ensure that MutexFuture::poll() will return Ok(futures::Async::Ready(x)) at some point. That is, the mutex is "reserved" for the future.

I guess it is sufficient with a method on RawMutex, but what and how? Is a new bitflag in the state needed?

Any thoughts?

from parking_lot.

Integrating support for futures seems to be quite a bit more involved than just calling try_lock in poll. The poll implementation also needs to call task::park to get a Task object which must be unparked when the mutex is released.

(though do correct me if I'm wrong, I'm not an expert on futures)

from parking_lot.

No, it's right. That was what I was trying to say: While my approach might work, it doesn't have to, and it is likely pretty slow if the mutex is locked all the time.

from parking_lot.

I think that implementing support for this would require pretty extensive modifications to the parking_lot_core mechanism. I think that you would be better off implementing a new Mutex type from scratch in a separate library.

from parking_lot.

cc. @alexcrichton

cc. @nikomatsakis

from parking_lot.

Maybe they have something to add.

from parking_lot.

I'm not really sure what the goals are with this issue. @ticki what exactly do you mean by "futures integration"? Maybe sketch out some use cases?

from parking_lot.

Yes I think we'd have to drill into what "futures integration" even means in this context to be able to add something.

from parking_lot.

I'm closing this issue since it seems to be outside the scope of parking_lot.

from parking_lot.

You're right. I'll make a crate for this.

from parking_lot.