Support for loop singletons

[vorner]

Hello

I'd like to have a singleton task in a loop. However, as it is a library, I don't want to make the user of the library manage it manually. So I want to have some way to associate information with a Core, so I can see if I already created the singleton or not.

My current motivation is to have a task that delegates unix signals to multiple futures inside the loop, more details can be found here: alexcrichton/tokio-signal#5.

I have two proposals how to do that (I'm going to make merge requests for them in a second). I would prefer the AnyMap one, as it seems to be more general and cleaner to use. The other is more lightweight and doesn't bring any additional dependency. Either one is good enough for my current need, but I'm not against merging both, as they can be used for potentially different things.

Any feedback is welcome (I'm a bit new to Rust, so I still have a lot to learn).

[vorner]

@alexcrichton, you said you wanted to discuss something here? Is the #149 OK with you? Or, do you have an idea for a nicer solution for the problem?

Thank you

[alexcrichton]

Oh yes don't worry I haven't forgotten about this. I just wanted to collect my thoughts. I'll post more tomorrow.

[alexcrichton]

Ok, some thoughts of mine:

• This definitely seems worthwhile to implement somehow to me. I can imagine a variety of applications that just want "one driver per core", sort of like a helper thread.
• I'd prefer to avoid too intrusive support in tokio-core itself but rather just provide the bare bones. Along those lines I think that CoreId in Provide a publicly-accessible Core ID #149 should be sufficient, right?
• We could also perhaps consider adding a generic abstraction to tokio-core, but I'm not sure what that would look like (not anymap) so we may wish to build it externally first.

[vorner]

I believe the CoreId should be sufficient to build it, but I'm afraid this'll require some kind of global storage under a mutex (eg. Mutex<HashMap<CoreId, MySingleton>>). It'll need to be checked and the singleton created on-demand if it doesn't exist and it'll have to delete itself from its own Drop, which seems a bit unelegant. That AnyMap didn't have this kind of restriction, but yes, it is kind of intrusive, that's why I proposed two options.

Just out of curiosity, is something wrong with AnyMap except that it's an intrusive change and an additional dependency (not that I'd want to push for it, I'm asking if there's something I don't see there)?

[alexcrichton]

For me at least AnyMap is rarely what you want in practice, it only ever seems nice in theory. That's just from my own personal experience though.

[vorner]

As #149 got merged, should we close this, or do we want to have an implementation that actually uses it, to confirm it would work? Or, should I close it, as the author of this?

[alexcrichton]

Closing sounds good to me!