[Haskell-cafe] readEitherChan

[Simon Marlow]

On 24 June 2004 21:24, S. Alexander Jacobson wrote:

> Cool! Why does it have an efficiency problem?

Because it does busy-waiting.

> And I would also observe that this solution
> doesn't work for readEitherChan because there is
> no tryReadChan.  The naive tryReadChan
> 
>     tryReadChan chan = if isEmptyChan chan then return Nothing else
> return $ readChan chan 
> 
> leaves you vulnerable to race conditions.
> 
> It looks like we have now have two very similar
> functions that, because they need the concrete
> representation, need to be added in the library:
> tryReadChan and tryReadSampleVar.
> 
> Is there a systemic reason why these two very
> similar functions are absent?  There is no point
> in my trying to add them if there is some *in
> principle* difficulty.

There's no fundamental difficulty that I'm aware of.  The lack of these
functions is probably down to historical reasons: tryTakeMVar and
tryPutMVar are recent additions to the old MVar interface.

> The concurrent paper seems
> to indicate that there is something fundamentally
> suspect about a choice operator as a primitive.
> Is that issue related?

The argument is based on the difficulty of implementing choice in a
multithreaded or distributed setting, and the fact that simplifications
to make the implementation easier tend to interfere with abstraction.

It seems to me that with MVars you can implement pretty much any
abstraction you need, including choice, and it's not clear that there
would be any advantage to providing any more primitives.  That's based
on my experience so far, anyway - I know there are people out there that
have made rather more heavy use of MVars than I have (eg. George
Russell).

> Also, you wouldn't need these functions if
> Haskell's concurency model was defined to be
> non-preemptive.  How come forkIO was not
> specifically defined to be non-preemptive (with
> forkOS dependent on the local OS native threading
> model)?

So threads forked by forkIO would be non-preemptive with respect to
what?  Other threads forked by forkIO, or forkOS?

forkOS is a very recent addition, BTW.  Its primary purpose is to make a
"bound" thread, to give the programmer a handle on which OS thread is
used to make foreign calls.  See this paper we submitted to the Haskell
Workshop this year:

http://www.haskell.org/~simonmar/papers/conc-ffi.ps.gz

Hope that sheds some light.

Cheers,
	Simon