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 cal
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 befor
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
>
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 means
Taral <[EMAIL PROTECTED]> writes:
> fast - takes very little time to execute
I was thinking about "quick". It seems to be less literal about speed
if my feeling of English is good enough; the effect is indeed not just
speed.
They fit both as a description of the foreign function, and as a
reques
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:
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
if I may repeat myself (again), since my old suggestion now seems to
agree with Wolfgang, Ross, and Simon:
http://www.haskell.org//pipermail/haskell-prime/2006-March/001129.html
...
so my suggestion would be to make no assumption about
unannotated calls (don't rely on the programmer t
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 s
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 m
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
Haskell
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 m
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 t
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 block
On 11 April 2006 17:49, Aaron Denney wrote:
> 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 not
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 si
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
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 impl
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 b
On 03-Apr-2006, John Meacham <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 03, 2006 at 02:00:33PM -0400, Wolfgang Thaller wrote:
> > About how fast thread-local state really is:
> > __thread attribute on Linux: ~ 2 memory load instructions.
> > __declspec(thread) in MSVC++ on Windows: about the same.
>
I think the following kinds of foreign calls wrt. concurrency are
sensible:
1. Other Haskell threads might get paused (but don't have to).
Examples: sqrt, qsort (we assume that qsort never needs a long time
between calls to the comparison function, so there is no need to
allow other thre
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
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 th
On Mon, Apr 03, 2006 at 02:00:33PM -0400, Wolfgang Thaller wrote:
> Sorry for the length of this. There are three sections: the first is
> about how I don't like for "nonconcurrent" to be the default, the
> second is about bound threads and the third is about implementing
> concurrent reentra
Sorry for the length of this. There are three sections: the first is
about how I don't like for "nonconcurrent" to be the default, the
second is about bound threads and the third is about implementing
concurrent reentrant on top of state threads.
no, state-threads, a la NSPR, state-threads
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 met
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 me
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
On Fri, Mar 31, 2006 at 06:41:18PM -0500, Wolfgang Thaller wrote:
> >I am confused, why would anything in particular need to happen at all?
> >
> >the threads are completly independent. The non-concurrent calls could
> >just be haskell code that happens to not contain any pre-emption
> >points
>
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 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 a
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 thi
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 again
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
On 30 March 2006 21:40, 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
> programmer an
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
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 i
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 t
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
"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
I updated the ForeignBlocking wiki page with what I believe is the
current state of this proposal; see
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ForeignBlo
cking
Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@ha
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
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 fo
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
"yie
On Thu, Mar 30, 2006 at 12:26:58PM +0100, Simon Marlow wrote:
> On 30 March 2006 11:42, John Meacham wrote:
>
> > Although I was skeptical at the beginning that we could come up with a
> > standard based on forkIO that could encompass both models without
> > compromising performance or implementat
On 30 March 2006 11:42, John Meacham wrote:
> Although I was skeptical at the beginning that we could come up with a
> standard based on forkIO that could encompass both models without
> compromising performance or implementation flexability, I now think
> that we can! and that is good, because it
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, du
On 29 March 2006 16:53, John Meacham wrote:
> On Wed, Mar 29, 2006 at 04:11:56PM +0100, Simon Marlow wrote:
>> Ok, let's explore how difficult it really is.
>>
>> Take a single-threaded implementation that forks OS threads for
>> concurrent foreign calls. Let's call the OS thread running Haskell
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 depen
On Wed, Mar 29, 2006 at 04:11:56PM +0100, Simon Marlow wrote:
> Ok, let's explore how difficult it really is.
>
> Take a single-threaded implementation that forks OS threads for
> concurrent foreign calls. Let's call the OS thread running Haskell code
> the "runtime thread". An OS thread wanting
here's another possible way to look at the complexities, and interactions
of FFI and Haskell' concurrency:
- we've been told here that concurrency is just a library
- GHC implements such a library
- all Haskell' implementations will support FFI
- FFI allows GHC to export that concurrency library
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 kn
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 Wed, 2006-03-29 at 07:32 -0600, Taral wrote:
> 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 unsa
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 e
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 29 March 2006 13:17, John Meacham wrote:
> On Wed, Mar 29, 2006 at 12:48:54PM +0100, Simon Marlow wrote:
>> I agree with what you say, but let me summarise it if I may, because
>> there's an assumption in what you're saying that's easy to miss.
>>
>> IF
>> the combination of 'blockable'
On Wed, Mar 29, 2006 at 12:48:54PM +0100, Simon Marlow wrote:
> I agree with what you say, but let me summarise it if I may, because
> there's an assumption in what you're saying that's easy to miss.
>
> IF
> the combination of 'blockable' and 'reentrant' is not
> required by the stan
I agree with what you say, but let me summarise it if I may, because
there's an assumption in what you're saying that's easy to miss.
IF
the combination of 'blockable' and 'reentrant' is not
required by the standard,
THEN
we should allow foreign calls to be annotated with
John Meacham <[EMAIL PROTECTED]> 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.
Yes. I have always found that naming convention confusing and
non-declarative. "Safe" mean
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.
> >
> > 'reentra
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' - rout
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 im
63 matches
Mail list logo
