Re: [Haskell-cafe] Implementing tryReadMVar

might be a reason to want to prefer one event over another.
You can still use a single channel... If you read all pending events on the channel into a FIFO (lazy list) then you can check for high priority events on read, and then deal with the next item on the top of the FIFO... something like the following (in pseudo code) while channel not empty read next event if event high priority process now else queue event in FIFO process first event in FIFO So inbetween processing low priority events we check ahead for any high priority ones... This could be extended with multiple FIFO's to deal with multiple priority levels... but this ensures all events are dealt with sequentially (if out of order)# Keean.

On 01.09 18:30, MR K P SCHUPKE wrote:
while channel not empty read next event if event high priority process now else queue event in FIFO process first event in FIFO
That suffers from the same problem as I described. do e <- isEmptyChan ch -- is the channel empty? case e of True -> processFifo False-> readChan ch >>= highPriorityOrPush Now there is danger of blocking on the readChan. (consider a case where we create two similar server processes reading the same channel). Now we create a tryReadChan, but we cannot implement it with tryTakeMVar, as that would break dupChan. Rather we need a tryReadMVar or a different channel abstraction. - Einar Karttunen
participants (2)
-
Einar Karttunen
-
MR K P SCHUPKE