headers
Brandon S Allbery KF8NH | 1 Jan 2011 19:35
Picon
Favicon

Re: Proposal: add forkOnIO and friends to Control.Concurrent:


On 12/22/10 06:41 , Simon Marlow wrote:
> Naming is up for grabs: I'm not at all sure that "capabilities" is a good
> word here, but I can't think of any better ideas.  "processors" or "CPUs"
> don't seem quite right.

Normally called kernel threads (as distinct from user threads), no?  Thread
multiplexing is far from unusual.

--

-- 
brandon s. allbery     [linux,solaris,freebsd,perl]      allbery <at> kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university      KF8NH
Permalink | Reply | 0 comments |
headers
Brandon S Allbery KF8NH | 1 Jan 2011 19:59
Picon
Favicon

Re: Proposal: add forkOnIO and friends to Control.Concurrent:


On 12/23/10 20:57 , Thomas Schilling wrote:
> I also find the name 'forkOnIO' extremely confusing.  Without reading
> the docs it seems to imply that a thread is created on IO, i.e., if
> I/O happens.  This makes no sense, and is of course not what's
> happening.  However, I assume you chose it because forkIOOn looks a
> bit weird.  In that case, why not use forkThreadOn, and in a separate
> proposal change forkIO to forkThread (or just fork).

+1
The name "forkIO" always seemed a bit odd to me; aren't threads pretty much
constrained to IO anyway?

--

-- 
brandon s. allbery     [linux,solaris,freebsd,perl]      allbery <at> kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university      KF8NH
Permalink | Reply | 7 comments |
headers
Eric Stansifer | 2 Jan 2011 02:03
Picon

SampleVar semantics

Hi,

I didn't get a response to my question on haskell-cafe, perhaps
libraries is a more appropriate place to ask.

doc:  http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/Control-Concurrent-SampleVar.html
source:  http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/src/Control-Concurrent-SampleVar.html

The isEmptySampleVar function,

isEmptySampleVar :: SampleVar a -> IO Bool
isEmptySampleVar (SampleVar svar) = do
  (readers, _) <- readMVar svar
  return (readers == 0)

returns False whenever readers < 0.  However, readers < 0 occurs when
there are threads waiting on an empty SampleVar.

The documentation on SampleVar is a bit sparse on explaining the
intended behavior;  I wouldn't have expected this behavior if I hadn't
read the source.  Can someone clarify the semantics of SampleVar?

For a contrived example, consider

do_something = threadDelay 100000     -- 100 ms

produce, consume :: SampleVar Int -> IO ()
produce svar = do
    do_something
    b <- isEmptySampleVar svar
(Continue reading)

Permalink | Reply | 4 comments |
headers
Maciej Piechotka | 2 Jan 2011 02:21
Picon

Re: Proposal: add forkOnIO and friends to Control.Concurrent:

On Sat, 2011-01-01 at 13:59 -0500, Brandon S Allbery KF8NH wrote:
> On 12/23/10 20:57 , Thomas Schilling wrote:
> > I also find the name 'forkOnIO' extremely confusing.  Without reading
> > the docs it seems to imply that a thread is created on IO, i.e., if
> > I/O happens.  This makes no sense, and is of course not what's
> > happening.  However, I assume you chose it because forkIOOn looks a
> > bit weird.  In that case, why not use forkThreadOn, and in a separate
> > proposal change forkIO to forkThread (or just fork).
> 
> +1
> The name "forkIO" always seemed a bit odd to me; aren't threads pretty much
> constrained to IO anyway?
> 

Depends on what you understand by thread:

> import Control.DeepSeq
> import Control.Parallel
> import Control.Seq
> 
> mergeSort :: (NFData a, Ord a) => [a] -> [a]
> mergeSort [] = []
> mergeSort [x] = [x]
> mergeSort xs = let (ys, zs)
>                       = foldr (\e (a, b) -> (e:b, a)) ([], []) xs
>                    merge xs [] = xs
>                    merge [] ys = ys
>                    merge s <at> (x:xs) t <at> (y:ys)
>                       | x < y = x : merge xs t
>                       | otherwise = y : merge s ys
(Continue reading)

Permalink | Reply | 5 comments |
headers
Brandon S Allbery KF8NH | 2 Jan 2011 02:30
Picon
Favicon

Re: Proposal: add forkOnIO and friends to Control.Concurrent:


On 1/1/11 20:21 , Maciej Piechotka wrote:
> On Sat, 2011-01-01 at 13:59 -0500, Brandon S Allbery KF8NH wrote:
>> On 12/23/10 20:57 , Thomas Schilling wrote:
>>> I also find the name 'forkOnIO' extremely confusing.  Without reading
>>> the docs it seems to imply that a thread is created on IO, i.e., if
>>> I/O happens.  This makes no sense, and is of course not what's
>>> happening.  However, I assume you chose it because forkIOOn looks a
>>> bit weird.  In that case, why not use forkThreadOn, and in a separate
>>> proposal change forkIO to forkThread (or just fork).
>>
>> +1
>> The name "forkIO" always seemed a bit odd to me; aren't threads pretty much
>> constrained to IO anyway?
> 
> Depends on what you understand by thread:

Implicit threading in the runtime doesn't actually count, no; if that isn't
referentially transparent then by definition it is broken.

--

-- 
brandon s. allbery     [linux,solaris,freebsd,perl]      allbery <at> kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university      KF8NH
Permalink | Reply | 4 comments |
headers
Maciej Piechotka | 2 Jan 2011 02:35
Picon

Re: Proposal: add forkOnIO and friends to Control.Concurrent:

On Sat, 2011-01-01 at 13:59 -0500, Brandon S Allbery KF8NH wrote:
> On 12/23/10 20:57 , Thomas Schilling wrote:
> > I also find the name 'forkOnIO' extremely confusing.  Without reading
> > the docs it seems to imply that a thread is created on IO, i.e., if
> > I/O happens.  This makes no sense, and is of course not what's
> > happening.  However, I assume you chose it because forkIOOn looks a
> > bit weird.  In that case, why not use forkThreadOn, and in a separate
> > proposal change forkIO to forkThread (or just fork).
> 
> +1
> The name "forkIO" always seemed a bit odd to me; aren't threads pretty much
> constrained to IO anyway?
> 

Depends on what you understand by thread:

> import Control.DeepSeq
> import Control.Parallel
> import Control.Seq
> 
> mergeSort :: (NFData a, Ord a) => [a] -> [a]
> mergeSort [] = []
> mergeSort [x] = [x]
> mergeSort xs = let (ys, zs)
>                       = foldr (\e (a, b) -> (e:b, a)) ([], []) xs
>                    merge xs [] = xs
>                    merge [] ys = ys
>                    merge s <at> (x:xs) t <at> (y:ys)
>                       | x < y = x : merge xs t
>                       | otherwise = y : merge s ys
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antoine Latter | 2 Jan 2011 07:12
Picon
Gravatar

Re: SampleVar semantics

I would file a bug on the GHC bug tracker:

http://hackage.haskell.org/trac/ghc/newticket?type=bug

You will need to use the guest login to trac, though (in grey text at
the bottom of the page).

I've also CCed the GHC-users list, as there are folks over there that
might have knowledge of the concurrency libraries.

Take care,
Antoine

On Sat, Jan 1, 2011 at 7:03 PM, Eric Stansifer
<eric.stansifer+haskell <at> gmail.com> wrote:
> Hi,
>
> I didn't get a response to my question on haskell-cafe, perhaps
> libraries is a more appropriate place to ask.
>
>
> doc:  http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/Control-Concurrent-SampleVar.html
> source:  http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/src/Control-Concurrent-SampleVar.html
>
> The isEmptySampleVar function,
>
> isEmptySampleVar :: SampleVar a -> IO Bool
> isEmptySampleVar (SampleVar svar) = do
>   (readers, _) <- readMVar svar
>   return (readers == 0)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Stansifer | 2 Jan 2011 08:03
Picon

Re: SampleVar semantics

Thanks, I've created a ticket.

http://hackage.haskell.org/trac/ghc/ticket/4876

Eric
Permalink | Reply | 0 comments |
headers
Isaac Dupree | 2 Jan 2011 08:16

Re: Proposal: add forkOnIO and friends to Control.Concurrent:

On 01/01/11 20:30, Brandon S Allbery KF8NH wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/1/11 20:21 , Maciej Piechotka wrote:
>> On Sat, 2011-01-01 at 13:59 -0500, Brandon S Allbery KF8NH wrote:
>>> On 12/23/10 20:57 , Thomas Schilling wrote:
>>>> I also find the name 'forkOnIO' extremely confusing.  Without reading
>>>> the docs it seems to imply that a thread is created on IO, i.e., if
>>>> I/O happens.  This makes no sense, and is of course not what's
>>>> happening.  However, I assume you chose it because forkIOOn looks a
>>>> bit weird.  In that case, why not use forkThreadOn, and in a separate
>>>> proposal change forkIO to forkThread (or just fork).
>>>
>>> +1
>>> The name "forkIO" always seemed a bit odd to me; aren't threads pretty much
>>> constrained to IO anyway?
>>
>> Depends on what you understand by thread:
>
> Implicit threading in the runtime doesn't actually count, no; if that isn't
> referentially transparent then by definition it is broken.

Kernel threads are an implementation detail, unless you need one for 
Thread-Local State or the like (using the poorly-named forkOS).

GHC threads are created by both forkIO and (usually) `par`.  `par` is 
referentially transparent because you can't observe GHC threads outside 
of IO, not because GHC threads aren't created by `par`.  (The "usually" 
is because the compiler and runtime is free to make a thread or not,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Malcolm Wallace | 2 Jan 2011 11:04
Gravatar

Re: Proposal: Change to library proposal process

>       A link to a patch implementing the change should be included.
>       Patches may be hosted anywhere

This "somewhere on the Internet" thing almost guarantees that the  
patch will not be archived for posterity alongside the discussion.  It  
makes future web-searches less useful than they could be.

Regards,
     Malcolm
Permalink | Reply | 24 comments |

Gmane