I cooked up a Darcs patch implementing the new language keyword 'interruptible'
sans tests, Windows support and avoiding executing interruptible calls on bound
worker threads. However, being a Darcs newbie I ended up sending the patch to
cvs-ghc, not this list. Let me know if you'd like me to exp
On 01/09/2010 04:22, Edward Z. Yang wrote:
Not sure what you mean here: what's a bound FFI call?
Good point: we don’t distinguish between FFI calls that require thread
local state and which ones don’t: this might be a good thing to allow
annotating. If we did know, then we could simply arrang
Excerpts from Simon Marlow's message of Tue Aug 31 05:02:13 -0400 2010:
> I think the idea of annotating interruptible calls should be good
> enough. Simple blocking system calls like "read" can all be annotated
> as interruptible without any problems. Also, pthread_cancel() provides
> ways to
On 28/08/2010 07:45, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Fri Aug 27 04:05:46 -0400 2010:
You should walk cap->suspended_ccalls instead, no lock is required for that.
For stress testing, you want to construct an example that has lots of
threads making foreign cals and o
Excerpts from Simon Marlow's message of Fri Aug 27 04:05:46 -0400 2010:
> You should walk cap->suspended_ccalls instead, no lock is required for that.
>
> For stress testing, you want to construct an example that has lots of
> threads making foreign cals and other threads calling throwTo to
> int
On 26/08/2010 18:20, Edward Z. Yang wrote:
Ahem, the logic in that last iteration was not quite correct.
Here is the more correct version:
case BlockedOnCCall:
case BlockedOnCCall_NoUnblockExc:
{
#ifdef THREADED_RTS
Task *task = NULL;
if (!target->bound) {
Ahem, the logic in that last iteration was not quite correct.
Here is the more correct version:
case BlockedOnCCall:
case BlockedOnCCall_NoUnblockExc:
{
#ifdef THREADED_RTS
Task *task = NULL;
if (!target->bound) {
// walk all_tasks to find the correct worker
Excerpts from Simon Marlow's message of Thu Aug 26 04:08:06 -0400 2010:
> You don't want to do this for a bound thread (when target->bound !=
> NULL), because the OS thread will have interesting things on its C stack
> and pthread_cancel discards the entire stack. A worker thread on the
> other
On 26/08/2010 08:10, Edward Z. Yang wrote:
Here is a possible implementation:
Task *task = NULL;
blockedThrowTo(cap,target,msg);
if (target->bound) {
// maybe not supposed to kill bound threads, but it
// seems to work ok (as long as they don't want to try
On 26/08/2010 06:57, Edward Z. Yang wrote:
Excerpts from Edward Z. Yang's message of Thu Aug 26 01:22:22 -0400 2010:
I spent some time looking at the code, and I've been having a difficult
time finding the thread ID of the worker thread that is performing the
safe FFI call. The target TSO is th
Here is a possible implementation:
Task *task = NULL;
blockedThrowTo(cap,target,msg);
if (target->bound) {
// maybe not supposed to kill bound threads, but it
// seems to work ok (as long as they don't want to try
// to recover!)
task = target->bound->ta
Excerpts from Edward Z. Yang's message of Thu Aug 26 01:22:22 -0400 2010:
> I spent some time looking at the code, and I've been having a difficult
> time finding the thread ID of the worker thread that is performing the
> safe FFI call. The target TSO is the suspended Haskell thread, which
> afai
Excerpts from Simon Marlow's message of Mon Aug 09 11:23:42 -0400 2010:
> That might be quite interesting to try, actually. You'll need to modify the
> RTS: the place where we decide what to do when a throwTo is received for a
> thread involved in a foreign call is around line 396 of rts/RaiseAsyn
On 06/08/2010 21:16, Edward Z. Yang wrote:
Excerpts from Corey O'Connor's message of Fri Aug 06 16:15:21 -0400 2010:
In your test cases that fail are your C computations foreign unsafe imports?
First thing I checked. :-) They were safe imports, and the Haskell code
did get called--just the C c
Excerpts from Corey O'Connor's message of Fri Aug 06 16:15:21 -0400 2010:
> In your test cases that fail are your C computations foreign unsafe imports?
First thing I checked. :-) They were safe imports, and the Haskell code
did get called--just the C code kept marching on.
Cheers,
Edward
___
On Fri, Jul 30, 2010 at 8:19 PM, Edward Z. Yang wrote:
> Hello all,
Hi!
> Ignoring the problems of cleaning up the unceremoniously terminated C
> computation, I'm having difficulty getting the FFI to /stop/ running
> when I get the signal. I currently have some code like this:
>
> http://hpa
Hello all,
I am currently investigating techniques to nicely handle SIGINTs when
FFI code is running. Yes, I know it sounds kind of crazy.
Ignoring the problems of cleaning up the unceremoniously terminated C
computation, I'm having difficulty getting the FFI to /stop/ running
when I get the sig
17 matches
Mail list logo
