| Yes, it definitely helps. It seems to be equivalent to "P1, but all
| foreign exports are bound".
Stupid me -- so it is! Yet you disliked P1 enough to put forward P2.
Was the 'main thread' thing the only reason?
| *) forkOS needn't be a primitive, it can be implemented via the FFI
(cf
| Section 3.2, first Proposal).
True, but clumsy; I think it should be in the spec.
| *) The semantics should probably have an (END) rule that specifies
that
| a thread created using forkIO can just end (without returning
anywhere).
Yes, I agree.
| *) We should perhaps add a primitive for querying whether the current
| thread is bound or not.
| This can be used for writing combinators that use forkOS only when
| necessary to make sure that we can access a foreign API that uses
| thread-local state.
| *) I don't think that a bindToOS primitive is really necessary,
| emulating it using forkIO shouldn't be noticably slower, IMO.
| *) We might sacrifice a little performance by making all foreign
| exports "bound". That should be paid back in simplicity. Hardcore
| hackers can always use forkIO to move work to a lightweight thread.
All good points -- would you like to add them to the document?
We seem to be converging!
| One issue remains however (and that's the topic of the rest of this
| e-mail); what to do about broken libraries that treat the "main" OS
| thread (i.e. the one that static initializers are run in) as special?
| This really happens; in fact both of Apple's GUI APIs are that
| brain-dead in the current version of Mac OS X.
I guess we can agree that we don't want to mess up the design for this
reason alone. We just need some workaround.
| So, our options seem to be
|
| 1) bind the "main" Haskell thread to the "main" OS thread
| 2) don't bind the "main" Haskell thread to the "main" OS thread
| 2a) complicate the system by adding a way to access the "main"
OS
| thread
| 2b) keep the system simple, use the hack I described above for
GHC
| programs that use Apple's libraries, and hope that Apple fixes it's
| libraries before people want to use them with other implementations of
| proposal4 where the hack doesn't work.
One might also add
We might add (3): on MacOS, arrange the GHC runtime so that it spawns a
thread to start and run Haskell, and then (in the main thread) calls in
to the Haskell export 'mainMacOs'... which will then be guaranteed to be
the main thread. Ugly though.
for (1), the main-thread binding could be on MacOS only; and that is
equivalent, but much less fragile, to your hack. So perhaps it'd do?
Simon
