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
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
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
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
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
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) {
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 =
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
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
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
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 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
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
afaict
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
On Fri, Jul 30, 2010 at 8:19 PM, Edward Z. Yang ezy...@mit.edu 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:
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
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
17 matches
Mail list logo
