Add support of a custom executor
This PR adds support of a custom executors (defaults to tokio::executor::DefaultExecutor).
Required bounds for supported executors are defined as MyExecutor trait.
New constructors:
Conn::with_executorConn::from_url_with_executorPool::with_executorPool::from_url_with_executor
Changes to existing code should be minimal because of default value for new type parameter on Pool and Conn.
@PvdBerg1998, could you please test this branch with your executor?
Looks great! I'll test it now.
I have a question: what happens when the Pool is dropped? Are existing connections dropped immediately? Because requiring the Executor in drop would mean trouble for my usecase and I think it's weird to do so. Or are the connections only cleaned up when manually calling disconnect?
The same concern I have about this function: https://github.com/blackbeam/mysql_async/blob/7a978e629f891b4d8d12312270aaa2a9131ac163/src/conn/mod.rs#L39 Also, this still is hardcoded to use tokio.
Edit: I think the disconnection should just be done in a blocking way inside Drop.
I found something weird: my process does not exit after main finishes? Details:
- The executor is halted, so it will fail to spawn a future.
- The database pool is dropped at the end of
main - Perhaps something is waiting forever inside a drop impl?
I found the issue: I have a wrapping type around a Pool, with a Drop impl that does this:
let _ = block_on(self.pool.clone().disconnect().compat());
Apparently this blocks forever when the executor is halted. Any idea how this could be prevented?
@blackbeam I would really like to fix this issue. Just fyi the PR most likely breaks something (or, hopefully, I'm doing something wrong) so it shouldn't be merged yet. If we wait until async await is stable and tokio is updated, I can move back to using tokio and this is no longer an issue. Still it is a nice flexibility feature but I expect tokio to get used most of the time