I spent some time this morning trying to use HDBC-mysql to talk to a
database. It uses the C mysql bindings, which talks over a blocking socket
to the database server. Not surprisingly, it fails reliably when the thread
it's running in is hit by an RTS-initiated alarm signal.
I've managed to make
Excerpts from Bryan O'Sullivan's message of Fri Sep 03 17:00:03 -0400 2010:
> What I am wondering is if there's a practical downside to doing this. Am I
> going to accidentally kill something? This is a very important gap in the
> usability of GHC with native libraries, and if this approach actuall
On Fri, Sep 3, 2010 at 2:13 PM, Edward Z. Yang wrote:
>
> I think the primary downside is that it's not portable (yet) to Windows.
That's fine, assuming that blocking those signals doesn't cause some more
catastrophic failure. My current narrow need is for code that works on the
platforms I act
On 03/09/2010 22:00, Bryan O'Sullivan wrote:
I spent some time this morning trying to use HDBC-mysql to talk to a
database. It uses the C mysql bindings, which talks over a blocking
socket to the database server. Not surprisingly, it fails reliably when
the thread it's running in is hit by an RTS
On 03/09/2010 22:13, Edward Z. Yang wrote:
Excerpts from Bryan O'Sullivan's message of Fri Sep 03 17:00:03 -0400 2010:
What I am wondering is if there's a practical downside to doing this. Am I
going to accidentally kill something? This is a very important gap in the
usability of GHC with native
Excerpts from Simon Marlow's message of Mon Sep 06 05:57:59 -0400 2010:
> What did you have in mind with respect to "portable equivalents of
> pthread functions"? I'm not sure we need to do anything along these
> lines at all, and I'd much rather we didn't enforce any threading
> abstraction on
On Mon, Sep 6, 2010 at 2:53 AM, Simon Marlow wrote:
> I think that should be fine - there should always be a worker thread in the
> system available to handle the signal. You could probably block those
> signals permanently for that thread.
>
Good to know, thanks.
> But why does the failure o
Hi!
On Tue, Sep 7, 2010 at 6:59 PM, Bryan O'Sullivan wrote:
> That's right. There's unfortunately a ton of library code out there that was
> written by people who don't know when EINTR can bite, and the mysql client
> library happens to be the most prominent one that affects the Haskell
> world.
Quoth "Bryan O'Sullivan" ,
...
> That's right. There's unfortunately a ton of library code out there that was
> written by people who don't know when EINTR can bite, and the mysql client
> library happens to be the most prominent one that affects the Haskell
> world.
I wouldn't bet my life all the
On 06/09/10 19:16, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Mon Sep 06 05:57:59 -0400 2010:
What did you have in mind with respect to "portable equivalents of
pthread functions"? I'm not sure we need to do anything along these
lines at all, and I'd much rather we didn't enf
Excerpts from Simon Marlow's message of Wed Sep 08 03:40:42 -0400 2010:
> Maybe. As a first step I think we could just document what happens when
> a call is interrupted (pthread_cancel() on POSIX, ??? on Windows) and
> let the user handle it. Is there even a good lowest-common-denominator
> t
On 08/09/2010 15:57, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Wed Sep 08 03:40:42 -0400 2010:
Maybe. As a first step I think we could just document what happens when
a call is interrupted (pthread_cancel() on POSIX, ??? on Windows) and
let the user handle it. Is there even
12 matches
Mail list logo
