Simon Marlow [EMAIL PROTECTED] writes:
I'd rather not, if we can avoid it. The only rationale I'll offer is that we
don't have it in GHC, and people manage to do a lot without priorities.
Priorities come with a whole can of worms that I'd rather not deal with.
Thread priorities are somewhere
Of course, let me know if I am just being overly paranoid about crazy
future NUMA machines. We can just say full read-write memory barrier on
every putMVar, takeMVar and leave it at that. :)
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
On 30 March 2006 22:01, Claus Reinke wrote:
the point being: the FFI says something about how to integrate
foreign and Haskell memory management; should it also say something
about threadability of foreign code (wrt to scheduling, and wrt
thread-safety)?
If Haskell' includes concurrency then
| Template Haskell breaks expressions with $,
|
| It's very bad that with TH enabled you cannot write sections of the
form ($ x)
| anymore which are sometimes very handy.
I'd prefer it if TH only sprang into action when you wrote
$x
or
$(f x)
That is, no space after the $. If
Sequence points... yes, all seems reasonable to me.
On 31 March 2006 00:50, John Meacham wrote:
We should drop atomicModifyIORef since we have MVars, for
architectures
with only a test and set instruction and no atomic exchange,
supporting atomicModifyIORef would entail the same overhead as
On Fri, Mar 31, 2006 at 01:43:15PM +0100, Simon Marlow wrote:
We should drop atomicModifyIORef since we have MVars, for
architectures
with only a test and set instruction and no atomic exchange,
supporting atomicModifyIORef would entail the same overhead as MVars.
Slightly less
On 31 March 2006 10:24, Bulat Ziganshin wrote:
Hello Simon,
Friday, March 31, 2006, 12:24:23 PM, you wrote:
threadSetPriority :: ThreadID - Int - IO ()
I'd rather not, if we can avoid it. The only rationale I'll offer is
that we don't have it in GHC, and people manage to do a lot
This is the way it is right now in GHC: the default is safe, and safe
means both reentrant and concurrent. This is for the reason you give:
the default should be the safest, in some sense.
..
So we can't have the default (unanotated) foreign call be something that
isn't required by the standard.
Hi everyone,
Before adding non-concurrent, reentrant calls to the language
standard, please take some time to think about what that means. If
you have forkIO'ed multiple threads, things start to interact in
strange ways. I think this is a can of worms we don't want to open.
(Or open
On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote:
Great. Apart from my misgivings about allowing cooperative scheduling
at all, here's a few comments on the proposal:
much much preferable to a standard that not everyone can implement. :)
- I wouldn't include threadWaitRead,
On Fri, Mar 31, 2006 at 03:16:50PM -0500, Wolfgang Thaller wrote:
Before adding non-concurrent, reentrant calls to the language
standard, please take some time to think about what that means. If
you have forkIO'ed multiple threads, things start to interact in
strange ways. I think this
I just realized that my mailer futzed this one and its headers don't
match where it was actually sent. so if you are responding to it, the
mail most likely is not going out to the list.
make sure it is to haskell-prime and not hasuell-prime.
John
--
John Meacham - ⑆repetae.net⑆john⑈
On Fri, Mar 31, 2006 at 03:16:50PM -0500, Wolfgang Thaller wrote:
So I'm going to ask a few questions about the semantics of non-
concurrent reentrant calls, and if people can provide answers that
don't scare me, I'll concede that they have a place in the language
standard.
first of all,
On Fri, Mar 31, 2006 at 01:51:14PM -0800, John Meacham wrote:
If so, we should specify what exception is raised if, say, forkIO is
called on such a system. We should also make it clear that
single-threaded implementations are required of things such as MVars.
Finally, we should add a
On 3/31/06, John Meacham [EMAIL PROTECTED] wrote:
- I wouldn't include threadWaitRead, threadWaitWrite,
or threadDelay at all. These can all be implemented using
FFI, so don't belong in the concurrency library. Their
presence is largely historical.
They all have special
On Fri, Mar 31, 2006 at 04:29:59PM -0600, Taral wrote:
On 3/31/06, John Meacham [EMAIL PROTECTED] wrote:
- I wouldn't include threadWaitRead, threadWaitWrite,
or threadDelay at all. These can all be implemented using
FFI, so don't belong in the concurrency library. Their
John Meacham wrote:
first of all, a quick note, for GHC, the answers will be the same
thing
it does now with -threaded. but I will try to answer with what a
simple
cooperative system would do.
Sure. Unless someone dares answer yes to question 4, GHC will stay
as it is.
2.) Assume
17 matches
Mail list logo
