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