Proposal: add forkOnIO and friends to Control.Concurrent:
ml at isaac.cedarswampstudios.org
Sun Jan 2 08:16:54 CET 2011
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).
>>> 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".
More information about the Libraries