Completion Ports and ODBC
-
Im dipping my toe into the murky waters of i/o completion ports.:confused: My app presently use threads to handle client connections , on for each connection. Naturally i now want to use i/o completion ports. Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads. I cant believe theres not support for this but ,as ever, the MS docs are very light on the subject. Dave
-
Im dipping my toe into the murky waters of i/o completion ports.:confused: My app presently use threads to handle client connections , on for each connection. Naturally i now want to use i/o completion ports. Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads. I cant believe theres not support for this but ,as ever, the MS docs are very light on the subject. Dave
Dave-B wrote: Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads. Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support.
-
Dave-B wrote: Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads. Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support.
Norm Almond wrote: Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support. As you state that SQL does not support overlapped read/writes, presumabley this means that IIS etc, are not truly scallable if the script uses database access X| . Thats a real bummer in the real world, though as i will have to have multi threads 'hanging around' for the database to return results. BTW thanks for your IOCP code. Dave
-
Norm Almond wrote: Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support. As you state that SQL does not support overlapped read/writes, presumabley this means that IIS etc, are not truly scallable if the script uses database access X| . Thats a real bummer in the real world, though as i will have to have multi threads 'hanging around' for the database to return results. BTW thanks for your IOCP code. Dave
With IOCP you have some worker-threads, normally I go for 2 - 4 four for each CPU in the machine. If everything is running fast and not waiting for anything, your completion port only uses a single thread for each CPU, but if one of those threads is "suspended" waiting for disk I/O, a database or something else, and a new socket connection is opened, the completion port uses a new thread to handle that connection. Basically IO Completion Ports is a mix between a threadpool and async. I/O ;) - Anders Money talks, but all mine ever says is "Goodbye!"