John Meacham [EMAIL PROTECTED] writes:
Checking thread local state for _every_ foregin call is definitly
not an option either. (but for specificially annotated ones it is
fine.)
BTW, does Haskell support foreign code calling Haskell in a thread
which the Haskell runtime has not seen before?
On 13 April 2006 10:02, Marcin 'Qrczak' Kowalczyk wrote:
John Meacham [EMAIL PROTECTED] writes:
Checking thread local state for _every_ foregin call is definitly
not an option either. (but for specificially annotated ones it is
fine.)
BTW, does Haskell support foreign code calling
Simon Marlow wrote:
I agree. So other suggestions? longrunning? mightblock or mayblock?
I don't like *block, because the question of blocking is irrelevant
to this issue. It's about whether the foreign call returns sooner or
later, not about whether it spends the time until then
On Wed, Apr 12, 2006 at 12:07:06PM -0400, Wolfgang Thaller wrote:
3) There might be implementations where concurrent calls run on a
different thread than nonconcurrent calls.
this is necessarily true for non-OS threaded implementations. there is
no other way to wait for an arbitrary C call to
On 4/12/06, Wolfgang Thaller [EMAIL PROTECTED] wrote:
Personally, I'm still in favour of inverting this. We are not in
court here, so every foreign function is guilty until proven
innocent. Every foreign function might be longrunning unless the
programmer happens to know otherwise. So maybe...
On Wed, Apr 12, 2006 at 04:40:29PM -0500, Taral wrote:
pure - side-effect free
we don't really need pure because not having an IO type in the result
implies pure.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
John Meacham [EMAIL PROTECTED] writes:
I object to the idea that concurrent calls are 'safer'. getting it
wrong either way is a bug. it should fail in the most obvious way
rather than the way that can remain hidden for a long time.
I wouldn't consider it a bug of an implementation if it makes
On Thu, Apr 13, 2006 at 12:43:26AM +0200, Marcin 'Qrczak' Kowalczyk wrote:
What about getaddrinfo()? It doesn't synchronize with the rest of the
program, it will eventually complete no matter whether other threads
make progress, so making it concurrent is not necessary for correctness.
It
John Meacham wrote:
This doesn't have to do with bound threads, [...]
I brought it up because the implementation you are proposing
fullfills the most important feature provided by bound threads,
namely to be able to access the thread local state of the main OS
thread (the one that runs C
On Wed, Apr 12, 2006 at 07:35:22PM -0400, Wolfgang Thaller wrote:
John Meacham wrote:
This doesn't have to do with bound threads, [...]
I brought it up because the implementation you are proposing
fullfills the most important feature provided by bound threads,
namely to be able to
John Meacham wrote:
However, in order to achieve that we would have to annotate the
foreign
functions with whether they use thread local state.
I am not opposed to that; however, you might not like that here
again, there would be the safe, possibly inefficient default choice,
which
On Wed, Apr 12, 2006 at 11:37:57PM -0400, Wolfgang Thaller wrote:
John Meacham wrote:
However, in order to achieve that we would have to annotate the
foreign
functions with whether they use thread local state.
I am not opposed to that; however, you might not like that here
again,
What are the conclusions of this thread?
I think, but correct me if I'm wrong, that the eventual outcome was:
- concurrent reentrant should be supported, because it is not
significantly more difficult to implement than just concurrent.
- the different varieties of foreign call should all
On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
- the default should be... concurrent reentrant, presumably, because
that is the safest. (so we need to invert the notation).
I think the name concurrent has a similar problem to safe: it reads
as an instruction to the
On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
What are the conclusions of this thread?
I think, but correct me if I'm wrong, that the eventual outcome was:
- concurrent reentrant should be supported, because it is not
significantly more difficult to implement than just
On 2006-04-11, Ross Paterson [EMAIL PROTECTED] wrote:
On Tue, Apr 11, 2006 at 09:13:00AM +0100, Simon Marlow wrote:
- the default should be... concurrent reentrant, presumably, because
that is the safest. (so we need to invert the notation).
I think the name concurrent has a similar
Hello John,
Tuesday, April 4, 2006, 5:55:19 AM, you wrote:
In my survey of when 'reentrant concurrent' was needed, I looked at all
the standard libraries and didn't find anywhere it was actually needed.
Are there some compelling examples of when it is really needed in a
setting that doesn't
On Sat, Apr 01, 2006 at 02:30:30PM +0400, Bulat Ziganshin wrote:
new stacks can be allocated by alloca() calls. all these
alloca-allocated stack segments can be used as pool of stacks assigned
to the forked threads. although i don't tried this, my own library
also used processor-specific
Hello John,
Monday, April 3, 2006, 12:53:05 PM, you wrote:
new stacks can be allocated by alloca() calls. all these
alloca-allocated stack segments can be used as pool of stacks assigned
to the forked threads. although i don't tried this, my own library
also used processor-specific method.
John Meacham wrote (... but I've reordered things):
My only real 'must-have' is that the 4 modes all can be explicitly and
unambiguously specified. I have opinions on the syntax/hints but
that is
more flexable.
I basically agree (the syntax discussion will take place in the years
after
Hello John,
Saturday, April 1, 2006, 4:53:00 AM, you wrote:
In an implementation which runs more than one Haskell thread inside
one OS thread, like ghc without -threaded or hugs, the threads are
NOT completely independent, because they share one C stack. So while
no, state-threads, a la
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 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
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,
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
On Thu, Mar 30, 2006 at 10:44:36AM +0100, Simon Marlow wrote:
You're optimising for the single-threaded case, and that's fine. In
GHC, a call-in is similar to what I outlined above except that we can
optimise away the RPC and perform the call directly in the OS thread
that requested it, due
It is not like inserting yields needs to be done much at all since we have
progress guarentees, so we know the program is doing something and on
any blocking call that could potentially take a while, the library will
yield for you.
where do we get the progress guarantees from? do we need a
On Thu, Mar 30, 2006 at 01:16:08PM +0100, Claus Reinke wrote:
It is not like inserting yields needs to be done much at all since we have
progress guarentees, so we know the program is doing something and on
any blocking call that could potentially take a while, the library will
yield for you.
On 30 March 2006 13:05, John Meacham wrote:
but the debugging/deterministic
benefits could be useful. you could be guarenteed to reproduce a given
sequence of context switches which could make finding concurrent
heisenbugs easier.
Actually +RTS -C0 already gives deterministic concurrency in
Simon Marlow [EMAIL PROTECTED] wrote:
I thought yhc supported unboxed values, so a loop like
count 0 = 0
count n = count (n - 1)
count 10
could block the runtime (assuming it was properly unboxed by the
compiler) since it never calls back into it and is just a straight
I updated the ForeignBlocking wiki page with what I believe is the
current state of this proposal; see
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the programmer annotating
the dangerous cases, instead of the safe cases?
On Thu, Mar 30, 2006 at 09:39:44PM +0100, Claus Reinke wrote:
I updated the ForeignBlocking wiki page with what I believe is the
current state of this proposal; see
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the programmer annotating
the dangerous cases, instead of the safe cases?
I think dangerous is a misleading term here. you are already using the
FFI, all bets are off. and it is
On Fri, Mar 31, 2006 at 12:52:11AM +0100, Claus Reinke wrote:
didn't I mention that concurrent may be inappropriate and misleading,
and that I think it is bad practice to rely on the programmer annotating
the dangerous cases, instead of the safe cases?
I think dangerous is a misleading
It would be nice if we can deprecate the not very informative 'safe'
and 'unsafe' names and use more descriptive ones that tell you what is
actually allowed.
'reentrant' - routine might call back into the haskell run-time
'blockable' - routine might block indefinitly
and it is not to hard to
On 29 March 2006 09:11, John Meacham wrote:
It would be nice if we can deprecate the not very informative 'safe'
and 'unsafe' names and use more descriptive ones that tell you what is
actually allowed.
'reentrant' - routine might call back into the haskell run-time
'blockable' - routine
On Wed, Mar 29, 2006 at 11:15:27AM +0100, Simon Marlow wrote:
On 29 March 2006 09:11, John Meacham wrote:
It would be nice if we can deprecate the not very informative 'safe'
and 'unsafe' names and use more descriptive ones that tell you what is
actually allowed.
'reentrant' -
On 3/29/06, Simon Marlow [EMAIL PROTECTED] wrote:
If we were to go down this route, we have to make reentrant the default:
'unsafe' is so-called for a good reason, you should be required to write
'unsafe' if you're doing something unsafe. So I'd suggest
unsafe
concurrent unsafe
On Wed, Mar 29, 2006 at 02:05:35PM +0100, Simon Marlow wrote:
will all have different concrete implementations and generate
different code. for correctness reasons, not efficiency ones.
Well, for correctness all you need is reentrant/blockable. If you have
that, all the others are
Malcolm correctly notes that when I say non-blocking I'm referring to
the behaviour from Haskell's point of view, not a property of the
foreign code being invoked.
In fact, whether the foreign code being invoked blocks or not is largely
immaterial. The property we want to capture is just this:
On 29 March 2006 14:35, John Meacham wrote:
On Wed, Mar 29, 2006 at 02:05:35PM +0100, Simon Marlow wrote:
What you are suggesting is that there may be implementations that do
not support reentrant/blockable, but do support the others. And in
that case, of course you really need to know the
Hi
- we've been told here that concurrency is just a library
No, its not. The interface to concurrency is just a library, but
internally certain things in the runtime have to change.
- FFI allows other Haskell' implementations to import that library
If all Haskell' prime implementations depend
43 matches
Mail list logo
