Proposal: add forkOnIO and friends to Control.Concurrent:

[Isaac Dupree]

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.)

For a programmer, it's useful to understand the difference between 
concurrency and parallelism.  But for an amateur understanding of the 
implementation, both programming-concepts use the same sort of 
GHC-threads.  I like the name "forkIO" because it says pretty much what 
it does: it creates ("forks") a second running IO.  It doesn't fork a 
process (Unix fork()), and it doesn't necessarily fork a kernel thread. 
  It does fork a Haskell thread (although it is not the only basic 
function that forks Haskell threads).

(Correct me if I'm wrong about the implementation.)

IMHO whether "threads [are] pretty much constrained to IO" does "depend 
on what you understand by thread".

I don't mind either name "forkIO" or "forkThread".

-Isaac