Hmm, this is a bit peculiar. The problem is you don't get
control over how gmapQ invokes the function toSql: it will
only ever be done with the type signature Data d = d - u.
There is good reason for this too: imagined you tried to run
gmapQ toSql on a data-type that contained a member that was
Where did 'query' come from?
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
message of Sun Apr 24 17:41:23 -0400 2011:
Edward Z. Yang ezy...@mit.edu writes:
I've been toying around with some ideas where we do alternative
forms of controlled mutation. One such idea has to do with memoization.
[..]
Hash tables take advantage of this fact by simply chaining together
Hello William,
You can find the state of the art (which isn't very advanced :-)
in debugging GHC compiled code with GDB here:
http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode
Maybe others can give more specific advice.
Cheers,
Edward
Excerpts from William Knop's message of
This is a fairly nontrivial problem. First off, let me tell you
what you do not /actually/ want to happen: you don't want the OS
level thread performing the foreign call to actually be killed;
most C code is not written a way that can gracefully recover from
this, and unless you have explicit
Hello all,
I'm interested in improving GHC's C-- parser's support (and also making
accomodations for the parser in our C-- pretty-printer) to the point
where we can round-trip output from -ddump-opt-cmm with no semantic
change. There are several roadblocks on the way here, but the one
I'm
Hello Svante,
I have a few recommendations, places where I'd check:
1. Consult the arguments passed to read() usign GDB (your libc has
debugging symbols) and see if they are obviously wrong. It seems
more plausible that they are something that would be right for
Linux, but not so right
Simon Marlow and I had this conversation not too long ago, and the answer
is no. However, this is definitely something that would be useful for
a lot of people (GHC developers included!)
Cheers,
Edward
Excerpts from Ryan Newton's message of Sun Apr 10 17:30:50 -0400 2011:
Hi cafe,
The
Excerpts from Grigory Sarnitskiy's message of Sat Apr 09 13:26:28 -0400 2011:
I guess that deciding whether two functions are equal in most cases is
algorithmically impossible. However maybe there exists quite a large domain
of decidable cases? If so, how can I employ that in Haskell?
In the
Excerpts from Karel Gardas's message of Thu Apr 07 13:14:46 -0400 2011:
OK! Thanks for the information. So this -fnew-codegen is this famous
codegen which is using hoopl for data-dependency tracking or something
like that if I understand correctly
Yep.
And which is producing just C-- in
checks for -dno-debug-output, though if some
tests are checking for debug output, that might be tricky.
Edward
Excerpts from Simon Marlow's message of Tue Apr 05 15:35:45 -0400 2011:
On 05/04/11 17:50, Edward Z. Yang wrote:
Hello all,
If I run 'make fast' in the testsuite, with a stage2
Hello all,
If I run 'make fast' in the testsuite, with a stage2 compiler that has been
built with -DDEBUG, should I be getting extra failures?
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
I don't know if there's a way to disable it, but you can wrap all your
spawned threads with an exception handler that catches BlockedIndefinitelyOnMVar
and ignores it. If the thread blocks indefinitely, it's as good as dead,
so there won't be any difference in behavior.
Cheers,
Edward
The main thing about FFI support is calling conventions, and LLVM supports
a variety of them, so if your LLVM code is using a calling convention
GHC supports, you should be able to manage it (there probably isn't any
toolchain support though, so you'll have to build the LLVM bits manually
and then
Excerpts from Jason Dagit's message of Tue Mar 29 00:43:10 -0400 2011:
I was reading up on the documentation for alloca and friends[1], which says,
If any of the allocation functions fails, a value of
Excerpts from Max Bolingbroke's message of Fri Mar 11 05:15:34 -0500 2011:
AFAIK this decision was reversed because SPJ found a simple way to
support them. Indeed, they work fine in 7.0.2 and generate warnings.
Correct. About a week-ish ago I submitted a patch to update the docs.
Cheers,
The trick is to write the rank-2 type in the function that runs
the monad, and leave the typeclasses skolemized.
Here's an example:
-- | Typeclass for monads that write or read to a network. Useful
-- if you define operations that need to work for all such monads.
-- You're expected to put
Excerpts from Oliver Charles's message of Mon Feb 21 08:53:48 -0500 2011:
Yes, this is a concern to me as well. The only places I've used
unsafePerformIO is with Query objects, which I am mostly treating as
immutable data, and never exposing anyway to modify query
objects.
That is a good way
Thanks Oliver!
I haven't had time to look at your bindings very closely, but I do
have a few initial things to think about:
* You're writing your imports by hand. Several other projects used
to do this, and it's a pain in the neck when you have hundreds
of functions that you
I was thinking it might be useful if we had a per-thread circular buffer in
memory for which we pushed a pointer to the info table we had just entered. In
the event of a crash, you could dump the contents of the buffer to see what
code had been recently executed. To reduce overhead, one might
:44:41 -0500 2011:
On 01/02/2011 00:01, Edward Z. Yang wrote:
Current theory:
c1jj:
_s1ep::I32 = I32[(slot_s1ep::I32 + 4)]; // CmmAssign
_s1fP::I32 = I32[(slot_s1fP::I32 + 4)]; // CmmAssign
// outOfLine should follow:
_s1eq::F64 = F64[_s1fP::I32 + 3
Current theory:
c1jj:
_s1ep::I32 = I32[(slot_s1ep::I32 + 4)]; // CmmAssign
_s1fP::I32 = I32[(slot_s1fP::I32 + 4)]; // CmmAssign
// outOfLine should follow:
_s1eq::F64 = F64[_s1fP::I32 + 3]; // CmmAssign
I32[(youngc1jh + 4)] = c1jh; // CmmStore
foreign
Test 4221 (under the ffi folder) segfaults with the new codegen turned on.
Before:
0xb7a68c78: 0x822fadc stg_ap_v_info
0xb7a68c74: 0xb7ab8f94
0xb7a68c70: 0xb7ab8fa4
0xb7a68c6c: 0x8134dc0 stT_info
0xb7a68c68: 0xb7ab8f94
0xb7a68c64: 0x822f9f4 stg_marked_upd_frame_info
Excerpts from Edward Amsden's message of Wed Jan 26 15:51:46 -0500 2011:
do
...
case ... of
Foo x - do ...
...
return foobar
Bar x - do ...
...
return foobar
There's not enough context here to say what is appropriate.
Hello Daryoush,
That is a good question, and depends on distinguishing between laziness
and nondeterminism. Suppose I have a normal, lazily evaluated list:
[1,2...]
There are thunks used in this case, but the end result is fully deterministic:
the next will always be 3, and then 4, and so
Yep, switching
inlineStmt u a (CmmCall target regs es srt ret)
= CmmCall (infn target) regs es' srt ret
where infn (CmmCallee fn cconv) = CmmCallee fn cconv
infn (CmmPrim p) = CmmPrim p
es' = [ (CmmHinted (inlineExpr u a e) hint) | (CmmHinted e hint) - es
to
inlineStmt u
Ok, I have a stage2 compiler built with the new codegen all
the way, and here are the new failing cases:
1372(normal)
2047(normal)
4030(normal)
OldException001(normal)
async001(normal)
bug1465(normal)
cabal01(normal)
cabal03(normal)
cgrun016(normal)
cgrun045(normal)
*you feel a sudden sense of deja vu*
Here is my current play on things:
- I can probably get a devel2 build with the new codegen turned on for
everything. This list of errors is from that build. However, this
build was originally failing, so I'm going to do a fresh devel2
Ok, here is an updated doc patch. I've also added
a substantial introduction section.
diff -rN -u old-base/Control/Concurrent/MVar.hs
new-base/Control/Concurrent/MVar.hs
--- old-base/Control/Concurrent/MVar.hs 2011-01-13 16:26:59.0 +
+++ new-base/Control/Concurrent/MVar.hs
I appear to have tracked down the bug for ffi021: the new
code generator doesn't appear to clear the tag bit for the
pointer to heap before:
// outOfLine should follow:
(_sR1::I32,) = foreign ccall
_sQR::I32((I32[_sRi::I32 + 7], `signed'),
Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
How would we get the current functionality of darcs-all pull? Is it even
possible?
Here is the rebase-y workflow. Untested, so I might have gotten one or two
details wrong.
Suppose I want to hack on GHC and base
With further poking, I think the new codegen is actually tickling
an existing bug in the native code generator optimizations, since
the cmmz output looks ok:
cSH:
_sQR::I32 = I32[_sRi::I32 + 3]; // CmmAssign
_sQS::I32 = I32[_sRi::I32 + 7]; // CmmAssign
These are interesting, opposed perspectives, and I suspect what would be
good is to treat both situations. I think perhaps what would be good
to put in the introduction is the conceptual model of MVars: that is,
take and put are the fundamental operations, and everything else is
composed of them.
If you load ghci into gdb, and then run it until the segfault, do
you get any interesting backtrace? Did you recently run software updates?
What happens if you reinstall GHC? Have you rebooted recently?
Cheers,
Edward
Excerpts from Michael Litchard's message of Wed Jan 12 21:07:30 -0500 2011:
Hello Simon,
Have you gotten a chance to look at these two hunks? (see below)
Thanks,
Edward
Excerpts from Edward Z. Yang's message of Fri Dec 10 10:59:26 -0500 2010:
Ok, I've got a patch that fixes this segfault. In the process I looked
at all patches to Cg* modules after Nov 2009 and
Hello Peter,
This is a classic problem with the normal monad type class. You can
achieve this with restricted monads, but there is a bit of tomfoolery
you have to do to get do-notation support for them.
Here is some relevant reading:
-
Haskell's type system makes large classes of traditional unit tests
irrelevant. Here are some examples:
- Tests that simply run code to make sure there are no syntax
errors or typos,
- Tests that exercise simple input validation that is handled by the
type system, i.e.
If you need multithreaded mutable arrays, TArray may be
a better choice, as the underlying stm implementation will manage locking
for you. (The current implementation isn't terribly efficient, but when
it gets better you'll get it for free too :-)
Wasn't that result John Launchbury's? I recalled hearing something similar
as well.
Cheers,
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Excerpts from Mitar's message of Fri Dec 24 23:18:43 -0500 2010:
I am not sure if this are really race conditions? The point is that
readMVar, withMVar and others do not return until they can return the
value back and after that the value is the same as it was at the
beginning of the call. So
Merry Christmas all!
Is it just me, or does the Control.Concurrent.MVar documentation seem a bit
misleading? In particular, we should explicitly note the race conditions
for not just swapMVar but also readMVar, withMVar, modifyMVar_ and modifyMVar,
and clarify that the safety guarantees of the
Here is one suggested doc patch. Comments and revisions welcome:
ezy...@javelin:~/Dev/ghc-clean/libraries/base/Control/Concurrent$ darcs
whatsnew -u
hunk ./Control/Concurrent/MVar.hs 59
{-|
This is a combination of 'takeMVar' and 'putMVar'; ie. it takes the value
- from the 'MVar', puts
Excerpts from Jacek Generowicz's message of Fri Dec 17 20:17:30 -0500 2010:
Imagine an activity which may be performed either by a computer, or
by a human (alternatively, either locally, or remotely across a
network). From Haskell's type system's perspective, these two will
look completely
It sounds like a good fit for your problem as stated. One thing to note
is that Haskell will give you great abstractions for very strong amounts
of code, as long as what you want to do is a good fit for the abstraction.
Haskell makes it quite hard to fit a square peg into a round hole, so
if one
Excerpts from Yves Parès's message of Wed Dec 15 13:28:11 -0500 2010:
if one day you decide you need an agent that generates random numbers
I could say that my agents now run in a certain monad, I just would have to
transform my basic agents to :
agent1 = liftM . fmap (*2)
(or even agen1
Ok, I've got a patch that fixes this segfault. In the process I looked
at all patches to Cg* modules after Nov 2009 and looked for changes that
weren't applied to the new codegen. I skipped the LLVM patch, but picked
up the rest of the blackhole changes. There are, however, two hunks that
I am
Hello all,
Here's an experience report for porting hoopl to manage MonoLocalBinds. The
Compiler.Hoop.XUtil module has a rather interesting (but probably common) style
of code
writing, along the lines of this:
fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block
Here is the new set of failing test-cases on the shiny new branch.
I should stick the merged branch somewhere; any suggestions?
4030(normal)
4221(normal)
IndTypesPerf(normal)
T1969(normal)
T3064(normal)
T3294(normal)
T3736(normal)
T3807(normal)
T4003(normal)
Ok, looking at 4030, which is this simple program:
main = do tid - block $ forkIO $ let x = x in x
killThread tid
It segfaults in stg_BLACKHOLE_info when attempting to
dereference... something (I haven't quite figured out
what yet; what's usually stored in 0x4(%esi) on 32-bit x86
when
I like Git for Computer Scientists [1] and Git in pictures [2]. It also
sounds like a Git for Darcs users might be in order.
Edward
[1] http://eagain.net/articles/git-for-computer-scientists/
[2] http://blog.nelhage.com/2010/01/git-in-pictures/
___
I've done a bit more chewing away at the branch and have gotten to
19Sep10.
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Final status report for tonight, before I crash in bed;
I've managed to make it compile all the way to hoopl.
It seems like hoopl doesn't typecheck anymore? I haven't
been following the typechecker changes too closely so
some guidance would be appreciated.
I get the same error for the other branch too.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
When I revert the PArr - ParallelArray changes in those directories,
I then get:
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.1.20101126 for i386-unknown-linux):
match_co
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Oh, that explains the co error! Thanks a bunch.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Excerpts from Brandon S Allbery KF8NH's message of Sat Dec 04 13:42:48 -0500
2010:
We went over this some time back; the GHC runtime is wrong here, it should
only disable flags when running with geteuid() == 0. Also, the current
mechanism for specifying runtime flags at compile time is
I fired up the new codegen and ran make fast on the regression suite
and the following new tests started failing:
3207(normal)
4030(normal)
cgrun016(normal)
cgrun045(normal)
cgrun051(normal)
dsrun005(normal)
dsrun007(normal)
dsrun008(normal)
exceptionsrun001(normal)
This was because, for some odd reason, the images were stored using
absolute URLs and not real wikilinks. I've fixed most of them on that
page.
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Great news and great stuff! Looking forward to playing around with it.
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hello John,
Arguably the correct thing to do is to use GHC's hooks for
programatically specifying runtime options; unfortunately, because
this has to run /before/ any Haskell code starts, it's a bit
unwieldly: essentially you'll need a C stub file that scribbles
the correct options into char
No, you're not totally screwed; you just need to bug xmonad-contrib
and category-extras to fix their code.
Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Excerpts from Simon Marlow's message of Wed Nov 17 06:15:46 -0500 2010:
I suggest keeping track of the number of items in the queue.
Ok, I added a spare_workers_no field to the Capability struct.
So I think the main thing missing is a call to workerTaskStop().
Added.
It would be really nice
Hello Ryan,
Adding the extra spare_workers_no field bookkeeping doesn't add very much
overhead, since whenever spare_worker's is changing we already have
taken out the lock.
As for using a lock-free data structures, I can't say I have a good
feel for how performance might change in that case.
Oh, there's quite a simple fix for this: don't have the FFI call
handle the SIGINT; only handle a signal the RTS generates. I guess
we should do a little more legwork to make sure interruptible(?) user threads
don't see signals.
Edward
___
Relatedly, it seems that it takes a nontrivial amount of time for
the multithreaded RTS to realize that a thread has emitted a
signal. I wonder if there's a more direct way an FFI call can say
when I get back to Haskell, immediately start propagating an exception.
Edward
Excerpts from Donn Cave's message of Thu Nov 11 17:07:20 -0500 2010:
ghc: 6.12.1
linux: 2.6.32
ncurses: 5.7
Someone probably should. It's tempting to conclude that the bug
is in ncurses, and perhaps it is, and maybe there's nothing to be
done about it anyway, but a language
I've been poking the bad behavior Brian described here:
http://blog.ezyang.com/2010/08/interrupting-ghc/comment-page-1/#comment-1334
and in the process noticed something kind of interesting about
thread scheduling in non-multithreaded mode (i.e. without -threaded).
When the single-threaded
I finally got some spare time to do some GHC hacking, and after feeling my
way around http://hackage.haskell.org/trac/ghc/ticket/4262 I came up with the
following patch, which appears to work (that is, bound the number of worker
threads hanging around after FFI calls):
diff -rN -u
Hello Dupont,
If your code follows good style and has kept as much code out of IO as
possible, you should be able to easily unit test the pure portions of your
code. Otherwise, classic integration tests, by setting up the network jigs
yourself, is standard.
Another little question:
How can I
Excerpts from Johannes Waldmann's message of Wed Oct 20 05:13:36 -0400 2010:
and indeed, gethostbyname is famous for being non re-entrant.
If you have the time, this would be a great time to improve the multithreaded
support of these libraries. In particular, glibc offers a re-entrant version
Hmm, in that case, one possibility is someone else did an FFI import of
gethostbyname and isn't using the same lock. Can you check for that?
Edward
Excerpts from Johannes Waldmann's message of Wed Oct 20 16:17:06 -0400 2010:
and indeed, gethostbyname is famous for being non re-entrant.
I'm a bit partial to Swift Mailer [1]. It's useful to support multiple
transport backends, especially in situations where sendmail is not
portable.
Cheers,
Edward
[1] http://swiftmailer.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Excerpts from Johannes Waldmann's message of Thu Oct 14 13:45:46 -0400 2010:
Is there a solution? Workaround? Better approach?
If it boils down to unsafePerformIO, then where do I put it,
and what should I watch out for?
unsafePerformIO is your ticket here. The key is to ensure all
of the
Excerpts from André Batista Martins's message of Sat Oct 09 17:45:05 -0400 2010:
Hello,
exists any algorithm to determine how terms can be changed to safisty the
type of one function?
Your terminology is a little off: in particular, your example doesn't include
any terms (which are
Excerpts from Gregory Collins's message of Wed Oct 06 19:44:44 -0400 2010:
I've got the month of October off, and one of the things I've been
planning on working on is a compliant HTML5 parser for Haskell --
something which is sorely needed! I will ping the list back if/when I
get it finished.
Excerpts from Ian Lynagh's message of Tue Sep 28 13:18:17 -0400 2010:
Yes, unless you make clean.
(it works by putting Validating=YES in mk/are-validating.mk)
Oof, ok, I bet that was what I was seeing.
Thanks,
Edward
___
Glasgow-haskell-users
Excerpts from Romain Demeyer's message of Tue Sep 28 09:06:53 -0400 2010:
That's what we want, but what is the explanation of this behavior? STM is
designed to be optimistic, not blocking. So, does it means that the value
is evaluated at commit-time?
Do you know some problems that are related
I wasted an afternoon compiling GHC with GhcDebugged = YES in my
mk/build.mk, only to have ghc-stage2 tell me it wasn't compiled
with -debug. Looking at mk/config.mk.in, it seems that GhcDebugged
is unconditionally set to NO. What am I doing wrong?
Edward
Here's what the Windows version would look like (if I could get HEAD
to build, that is :-)
void
interruptOSThread (OSThreadId id)
{
HANDLE hdl;
PCSIO pCSIO;
if (!(hdl = OpenThread(THREAD_TERMINATE,FALSE,id))) {
sysErrorBelch(interruptOSThread: OpenThread);
Excerpts from Günther Schmidt's message of Fri Sep 17 13:27:45 -0400 2010:
I'd want to create a EDSL where I want to be able to statically ensure
that expressions can only be built according to a particular state.
Like in a network application, SMTP client for example, where I can only
Excerpts from Neil Davies's message of Fri Sep 17 05:27:34 -0400 2010:
Why not use kerberos?
We find it works for us, integrates with web (natively or via
WebAuth), remote command execution (remctl) and ssh - widely used,
scales brilliantly.
MIT uses Kerberos and it is quite nice to be
There are some invariants that are being violated by pthread_kill(id, SIGINT)
and I'm having difficulty understanding them. I get the following errors:
cd ./concurrent/should_run '/home/ezyang/Dev/ghc/inplace/bin/ghc-stage2'
-fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -rtsopts
It looks like the problem was that the default handler for SIGINT
was scheduling code to run, when we really just wanted to get EINTR.
I'm sketchily using SIGPIPE right now; maybe we should use SIGUSR1
or something.
Edward
___
Glasgow-haskell-users
Excerpts from Simon Marlow's message of Wed Sep 15 04:34:06 -0400 2010:
It's not clear to me when to emit the warning: the system we're
compiling on is not necessarily the one we're going to run on. This is
more often the case for us where we're building distributions, than for
other
Excerpts from Simon Marlow's message of Mon Sep 13 05:10:13 -0400 2010:
The idea of having user-definable cancellation mechanisms seems quite
sensible, given that we have so many ways to do this. However it seems
quite hard in practice: for pthread_cancel, the RTS has to behave quite
A possible cute solution would be to ulimit the processes
permitted cpu time.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Excerpts from Ertugrul Soeylemez's message of Mon Sep 13 03:03:11 -0400 2010:
In general it's better to avoid using killThread. There are much
cleaner ways to tell a thread to exit.
This advice doesn't really apply to Haskell: in fact, the GHC developers
have thought really carefully about
So I did a writeup of what I thought might be the next direction to
go with the interruptible patch:
http://blog.ezyang.com/2010/09/towards-platform-agnostic-interruptibility/
The really interesting bit (which I didn't cover) is what information
to give to the user functioSo I did a writeup
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
that
Excerpts from Johannes Waldmann's message of Tue Sep 07 10:38:47 -0400 2010:
Yuras Shumovich shumovichy at gmail.com writes:
http://hackage.haskell.org/trac/ghc/ticket/3910
So what is the magic link-time flag to en/disable the RTS options?
As you mentioned earlier, -rtsopts.
It seems it
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
Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400 2010:
I feel like the circular imports problem is worse in haskell than
other languages. Maybe because there is a tendency to centralize all
state, since you need to define it along with your state monad. But
the state monad
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 actually
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
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
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 =
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
201 - 300 of 364 matches
Mail list logo
