On 09/03/2010 06:14 PM, David Powell wrote:
Hi John,
My current usage of hdbc is in a server process that takes requests from
multiple clients, queries the database, and returns a result. Having a
single db query block everything else isn't really workable for me. I
suspect this will also be an issue for others. As an example, the
persistent-postgresql package which is part of the new Yesod web
framework will have the same problem.
I can send you a patch, but I am concerned with the issue Leon raised
about libpq needing to be compiled with thread support. This is the
default on my platforms (macosx, debian), but probably is dangerous to
rely on. I guess we can just test the result of 'PQisthreadsafe()', in
connectPostgreSQL and raise an error if it is false.
Or at least a warning to stderr -- that won't be a problem for
single-threaded programs, right?
Cheers,
-- David
On Fri, Sep 3, 2010 at 1:36 AM, John Goerzen <[email protected]
<mailto:[email protected]>> wrote:
Hi David,
I've had varying arguments from people that want me to mark things
safe or unsafe for various performance reasons. I'm happy to apply
your change if you like. Can you send me a diff (and attach your
explanation here to it, which I'll use as a commit message for
future reference)?
Thanks,
-- John
On 09/01/2010 09:40 PM, David Powell wrote:
Greetings,
I'm having an issue with the HDBC-postgresql package that
requires me to
manually patch it before installation for most of my use cases.
All the FFI calls in this package are marked "unsafe".
Unfortunately,
this means that whenever I issue a slow sql query, all other
processing
stops. In most places that I want to use this module, I've had to
manually patch it to at least mark the PQexec and PQexecParams
calls as
"safe".
Is there any reason these calls should not be marked as "safe"? I
understand that there a little extra runtime overhead with this,
but I'd
have thought that negligible given all the other processing that
goes on
with these particular calls under the hood.
Cheers,
--
David Powell
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
