Proposal: add forkOnIO and friends to Control.Concurrent:

[Brandon S Allbery KF8NH]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/2/11 02:16 , Isaac Dupree wrote:
> 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, since it
> *is* referentially transparent regardless of this choice.)

Exactly.  I look at this as:  `par` is a hint, the implementation might or
might not thread.

Maybe I need to rephrase my point:  *explicit* threading, almost by
definition, must be in IO.  *Implicit* threading is an implementation
detail; `par` might or might not create a thread, since it's a hint, and (at
least in theory if not in actual practice as yet) the runtime could
autothread things without a hint if it can determine that there would be a
benefit.

In any case, all of this is kind of beside the point:  "forkIO" implies a
"forkNotIO" of some kind (explicit pure threads) which doesn't exist and
probably can't exist usefully.  `par` is more of an optimization hint, in my
mind, directed at an optional implicit threader that is free to ignore the
hint and even potentially fire on its own in the absence of `par`.

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0gsygACgkQIn7hlCsL25WN4ACggqDky1PteVc/8QFKVD4SPTSB
aBkAnRDPhqzMIp34pdr5CrQeueNlP0bg
=KWMK
-----END PGP SIGNATURE-----