RE: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-11 Thread Simon Marlow
> The logical dual to tryTakeMVar would be >tryPutMVar :: MVar a -> a -> IO Bool tryPutMVar :: MVar a -> a -> IO Bool tryPutMVar m a = Exception.catchAllIO (do { putMVar m a; return True }) (\e -> case e of PutFullMVar -> ret

Re: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-11 Thread George Russell
Simon Marlow wrote: > The only way I can see to do this is to add a lock field to the MVar. And > since this lock would look very much like another MVar, you may as well just > use another MVar to lock it (after all, that adds exactly zero extra > complication to the system :-). Absolutely. > The

RE: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-11 Thread Simon Marlow
> Marcin 'Qrczak' Kowalczyk wrote: > > MVars should be simple. They are building blocks for more complex > > things. > I completely agree. But _if_ it should happen that my proposal could > be implemented without making anything else more complicated, > it would be > the most logical new primiti

RE: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-10 Thread Simon Peyton-Jones
This seems pretty sensible to us. We'll try it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] | Sent: 08 April 2000 20:44 | To: [EMAIL PROTECTED] | Subject: tryTakeMVar :: MVar a -> IO (Maybe a) | | | Wouldn't be nice to have such fun

Re: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-10 Thread George Russell
Marcin 'Qrczak' Kowalczyk wrote: > MVars should be simple. They are building blocks for more complex > things. I completely agree. But _if_ it should happen that my proposal could be implemented without making anything else more complicated, it would be the most logical new primitive. If not, th

Re: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-10 Thread Marcin 'Qrczak' Kowalczyk
Mon, 10 Apr 2000 10:50:35 +0200, George Russell <[EMAIL PROTECTED]> pisze: > Would it be possible to implement an operation to lock an MVar > without any extra expense? So that the thread owning the MVar can > do things to it, but no other thread can. What does "lock" mean? takeMVar is a kind o

Re: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-10 Thread George Russell
Would it be possible to implement an operation to lock an MVar without any extra expense? So that the thread owning the MVar can do things to it, but no other thread can. If it is possible, I suggest that it be added and it would solve Marcin's problem (isEmptyMVar would then suffice).

Re: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-10 Thread Marcin 'Qrczak' Kowalczyk
10 Apr 2000 05:46:31 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze: > (but tryTakeMVar would suffice for isEmptyMVar). Well, not exactly. -- __("$ P+++ L++>$

Re: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-09 Thread Marcin 'Qrczak' Kowalczyk
Sun, 9 Apr 2000 13:54:47 -0700, Sigbjorn Finne <[EMAIL PROTECTED]> pisze: > > Wouldn't be nice to have such function? > > Have you tried using Concurrent.isEmptyMVar ? isEmptyMVar is not enough to implement tryTakeMVar (but tryTakeMVar would suffice for isEmptyMVar). Just after checking that it

RE: tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-09 Thread Sigbjorn Finne
> > Wouldn't be nice to have such function? > Have you tried using Concurrent.isEmptyMVar ? --sigbjorn >

tryTakeMVar :: MVar a -> IO (Maybe a)

2000-04-08 Thread Marcin 'Qrczak' Kowalczyk
Wouldn't be nice to have such function? I wanted to translate a thread example written in Ruby and realized that it's impossible to write that function using MVar primitives provided; and no module seems to provide an equivalent using another kind of concurrent variable. I had to simulate mutexes