Feature #77
HDBC, FFI and blocking foreign calls
| Status : | Feedback | Start : | 06/10/2008 | |
| Priority : | Normal | Due date : | ||
| Assigned to : | - | % Done : | 0% |
|
| Category : | - | |||
| Target version : | - | |||
| Resolution : |
Description
Hi,
All foreign calls in the ODBC driver (and maybe other drivers) are marked as unsafe. While making their single threaded performance better[1], it also means that while accessing the database all threads are blocked[2]. Is this a good trade-off?
A database can be located on another server and can therefore have relative large latency. Thus we may spend a good deal of CPU horsepower doing nothing, as unsafe makes all threads block. I can easily imagine two scenarios where this would be problematic.
1) A concurrent web-application serving many clients at once. If we have ten clients active at the same time, do we really want all threads blocking when one is accessing the database?
2) A GUI front-end for a database. When the user has requested a long running query, do we really want the hole GUI to block while it is being processed? Also if the user is trying to connect to a database and the connection is hanging, so will the GUI - potentially forever.
Unless there is some serious performance issues with unsafe-foreign calls, I think it would be wise to change them to safe-foreign calls.
All that said, I have very little experience with foreign calls. I just stumbled into the problem as I was experiencing a hanging call to odbcConnect.
Greetings,
Mads Lindstrøm
[1] http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Improving_efficiency
[2] http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4
History
06/11/2008 02:32 PM - John Goerzen
- Status changed from New to Feedback
Hi Mads,
Well this was probably done for several reasons.
1) The definition of safe vs. unsafe seems to have evolved over time. The FFI spec seemed to refer to it more as dealing with reentrancy, but it may be different now.
2) I didn't have details on what sort of threading was guaranteed to work with ODBC implementations on different platforms.
If you can find information on what ODBC supports, I would accept a well-tested, well-designed patch that is accompanied by supporting documentation to change the behavior. To me, ODBC is still somewhat of a black box and I am hesitant to touch it without solid feedback from people that have tested it.
06/14/2008 02:33 AM - Mads Lindstrøm
Hi John,
I can see your point about the multi-thread support of ODBC. Looking at the web it seems like a mess. Some drivers seem to support multi-threading, some seems not to support it. And "seems" is the right word here, as it is hard to find anything definitive. Of cause, one could look at the ODBC ISO standard. That is, if one has access to it. But even if the standard requires thread safety, it do not help much if half the drivers are not thread safe.
Another way would be to serialize all database access in HDBC. This way, foreign calls could be marked as safe, while still ensuring thread safety. It could even be possible, for the user of HDBC, to turn the "serializing" off, if he were confident that the driver were thread safe. Of cause this would come with warnings and not be default.
Regarding implementation, I have no time to implement it currently. And I doubt I will get it in the future.
Greetings,
Mads