[Note: I'm consistently using 'foreign thread' instead of 'native
thread'. The Haskell-spec necessarily treats Haskell as the centre of
the universe. So what a Linux kernel hacker might think of as a
'native thread' is really quite foreign to Haskell. Feel free to
ignore this little experiment
Or, we can adopt a much weaker semantics than Wolfgang
intended and have:
$0 = bindees(f) - uses(f)$
This would allow several currently running, active Haskell threads to
all be bound to the same foreign thread. When any of these threads
makes a foreign call, the other threads
I too am getting link times in the several minutes range for
my modestly
sized project, I am on a standalone dual-cpu redhat linux box with
5.04.1 (no nfs, no nuttin')
the project is available at
http://repetae.net/john/computer/ginsu/
I think there is definatly something fishy going
I haven't been able to discern any pattern among those experiencing long
link times so far, except that -export-dynamic flag used by the dynamic
loader stuff seems to cause the linker to go off into space for a while.
We're still investigating here, but just a quick summary for our own
(large)
Simon Marlow:
Another problem, from an implementation point of view, is that we
would have to surround unsafe foreign calls with a lot of
context-switching gumph, in case the calling Haskell thread is bound
to a native thread. I really think we don't want to do this.
Note that you only
This is all getting highly confusing, as it seems we're working with
different ideas of what's on the table. Alastair: you seem to be
working on your own proposal - could you write it down either as a
complete proposal or diffs to Wolfgangs?
I did. You sent comments on it and I sent
So, we can say that foreign functions of the form:
foreign import bound unsafe bar :: ...
are illegal or we can allow them and provide warnings or we can allow
them and trust the programmer to know that bar is much more expensive
than they think. (I favour the first two.)
NOOO! Don't do
