roger peppe wrote:
By the way, where does FRP (which I haven't got my head around yet)
sit with respect
to STM?
Entirely orthogonal.
FRP is not generally thought of as (explicitly) threaded at all. It's
more declarative than that. It's also supposed to be deterministic (up
to the
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.
The problem is that in order for synchronization to happen, you need
both sides to be able to
On Thu, Oct 9, 2008 at 12:29, roger peppe [EMAIL PROTECTED] wrote:
It's useful, thanks, but not really what I was originally looking for.
Synchronous channels are generally easier to reason about (less states
to deal with).
Right, that's very true. Interaction between transactions is naturally
On Thu, Oct 9, 2008 at 9:15 AM, Ryan Ingram [EMAIL PROTECTED] 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
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
On Thu, Oct 9, 2008 at 10:50, roger peppe [EMAIL PROTECTED] wrote:
On Thu, Oct 9, 2008 at 9:15 AM, Ryan Ingram [EMAIL PROTECTED] 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
On Thu, Oct 9, 2008 at 10:12 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Sorry, I come into this discussion late. One-place buffers, or MVars,
are indeed implemented over STM in the orignal paper [1].
Yes, I should have remembered that. It's ok just as long as
there's a buffer there because
On Wed, Oct 8, 2008 at 3:10 PM, roger peppe [EMAIL PROTECTED] wrote:
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv
primitives
on a channel that each block until the other side arrives to complete
the
On Thu, Oct 9, 2008 at 1:50 AM, roger peppe [EMAIL PROTECTED] wrote:
On Thu, Oct 9, 2008 at 9:15 AM, Ryan Ingram [EMAIL PROTECTED] 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
Hi there,
2008/10/9 David Leimbach [EMAIL PROTECTED]:
see writeTChan and readTChan. I assume readTChan is synchronous :-).
writeTChan may be asynchronous for all I can tell (haven't looked deeply).
writeTChan is asynchronous, i.e. channels in this case are unbounded buffers.
But I did
On Thu, Oct 9, 2008 at 18:10, Arnar Birgisson [EMAIL PROTECTED] wrote:
But I did write a concurrent prime sieve with it:
I did the same, with the one-place-buffers (the MVars implemented over
STM). Be warned that there is no stop condition, this just keeps
printing primes forever.
Please
This seemed like an interesting problem, so I whipped together a
quick-and-dirty implementation of transactional CML semantics in
Haskell using STM.
Example:
main = do
forkIO chsThread -- administrative thread that manages communication
forkIO (synchronize test1 = print)
synchronize
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv primitives
on a channel that each block until the other side arrives to complete
the transaction.
I think I've convinced myself that it's not possible, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
roger peppe wrote:
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv primitives
on a channel that each block until the other side arrives to complete
the
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv primitives
on a channel that each block until the other side arrives to complete
the transaction.
Assuming that retry blocks until something changes, you could
2008/10/9 Claus Reinke [EMAIL PROTECTED]
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv
primitives
on a channel that each block until the other side arrives to complete
the transaction.
Assuming that
16 matches
Mail list logo
