-----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@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@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-----