FFI, safe vs unsafe
John Meacham
john at repetae.net
Wed Apr 12 16:21:59 EDT 2006
On Wed, Apr 12, 2006 at 12:07:06PM -0400, Wolfgang Thaller wrote:
> 3) There might be implementations where concurrent calls run on a
> different thread than nonconcurrent calls.
this is necessarily true for non-OS threaded implementations. there is
no other way to wait for an arbitrary C call to end than to spawn a
thread to run it in.
This doesn't have to do with bound threads, to support those you just
need to make sure the other thread you run concurrent calls on is always
the same thread. it is the cost of setting up the mechanism to pass
control to the other thread and wait for the response that is an issue.
turning a single call instruction into several system calls, some memory
mashing and a context switch or two.
I object to the idea that concurrent calls are 'safer'. getting it wrong
either way is a bug. it should fail in the most obvious way rather than
the way that can remain hidden for a long time.
in any case, blocking is a pretty well defined operation on operating
systems, it is when the kernel can context switch you away waiting for a
resource, which is the main use of concurrent calls. the ability to use
them for long calculations in C is a sort of bonus, the actual main use
is to ensure the progress guarentee, that if the OS is going to take
away the CPU because one part of your program is waiting for something
another part of your program can make progress. Which is why I'd prefer
some term involving 'blocking' because that is the issue. blocking calls
are exactly those you need to make concurrent in order to ensure the
progress guarentee. sayng something like 'takesawhile' muddies things,
what is a while? not that concurrent calls shouldn't be used for long C
calculations, it is quite a nice if uncommonly needed perk, but I don't
want the report to confuse matters by making a quantitative real matter,
meeting the progress guarentee, with a qualitiative one "does this take
a while". I'd actually prefer it if there were no default and it had to
be specified in neutral language because I think this is one of those
things I want FFI library writers to think about.
John
--
John Meacham - ⑆repetae.net⑆john⑈
More information about the Haskell-prime
mailing list