Bug #40288 BeginExecuteReader and BeginExecuteNonQuery should really perform non-block IO

• Submitted: 23 Oct 2008 19:14
• Modified: 10 Nov 2008 19:32
• Reporter: Bassam Tabbara
• Status: Not a Bug
• Category: Connector / NET
• Severity: S4 (Feature request)
• Version: 5.2.3
• OS: Any
• CPU Architecture: Any

[23 Oct 2008 19:14] Bassam Tabbara

Description:
Currently invoking BeginExecuteReader and BeginExecuteNonQuery queues uses the delegate.BeginInvoke method which internall just adds the work to the ThreadPool Queue. This could result in a large number of threads running, worst case being one thread per command execution.

How to repeat:
None needed.

Suggested fix:
The MySQL Driver abstraction should support asynchronous Query() operations that perform asynchronous I/O to MySQL. BeginExecuteReader and BeginExecuteNonQuery can call these instead and perform a truly asynchronous operation.

[7 Nov 2008 19:49] Reggie Burnett

MySql doesn't support async I/O.  The only way to approximate async i/o with mysql is with server side prepared statements with a page size of 1 and that would have way too much overhead for what we are doing.  Hopefully we will support a true async model in the future.

[10 Nov 2008 19:32] Bassam Tabbara

I understand that the MySQL engine does not support async I/O.
 
I was wondering if the network operation (such as sending a PREPARE operation) on the connector side can be done asynchronously. This way the connector is not holding a thread while waiting for a response from MySQL.

[11 Nov 2008 15:46] Reggie Burnett

Bassam

Yes, technically, the driver could use async socket calls to make this happen however that would complicate the driver a great deal.  First, we support not only socket connections but named pipe and shared memory connections so we would need to approximate an async call on those protocols.  

It's not enough to do the async call but the driver would need to find a way to give control back to the app to make it worthwhile.  Also, the .net implementation of non-blocking socket calls would use threads from the worker thread pool (which we don't really want to do).  To avoid this I would need to use my own threading and pinvoke to the socket calls which would cause problems when running under Mono on Linux.

It would cause more trouble than it is worth I think.