[Haskell-cafe] synchronous channels in STM

[Andrea Vezzosi]

I'd rather say that STM is intended to be used just for building up
transactions, not to model your whole process/thread, simply because in the
latter case your process couldn't have any observable intermediate state, or
put in another way, between any two transactions the information can only go
in one direction.
So, since synchronizing two processes needs bidirectional communication, you
have to use more than one transaction.
In the end you still write processes in IO, but communicate via transactions
built in STM.

It's a good thing to expose your primitives as STM when you can, so that
users can build larger transactions on top of them, but a synchronous send
is not a transaction from the start so there's no choice.


2008/10/9 roger peppe <rogpeppe at gmail.com>

> On Thu, Oct 9, 2008 at 9:15 AM, Ryan Ingram <ryani.spam at gmail.com> wrote:
> > I don't think what you want is possible if both sides are in STM.
> > Other authors have posted solutions where one side or the other of the
> > transaction is in I/O, but wholly inside STM it's not possible.
>
> Thanks, that's what I thought, although I wasn't sure of it, being
> new to both Haskell and STM.
>
> Presumably this result means that it's not possible to implement
> any bounded-buffer-type interface within (rather than on top of) STM.
>
> Isn't that a rather serious restriction?
>
>  cheers,
>    rog.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081009/efb14c10/attachment.htm