Proposal: Improve the API for TChan, TMVar, and TVar
Bas van Dijk
v.dijk.bas at gmail.com
Sun Mar 27 01:04:14 CET 2011
On 26 March 2011 21:30, wren ng thornton <wren at freegeek.org> wrote:
> On 3/26/11 11:43 AM, Antoine Latter wrote:
>>
>> On Sat, Mar 26, 2011 at 6:26 AM, Bas van Dijk<v.dijk.bas at gmail.com>
>> wrote:
>>>
>>> On 26 March 2011 10:29, wren ng thornton<wren at freegeek.org> wrote:
>>>>
>>>> tryReadTChan :: TChan a -> STM (Maybe a)
>>>
>>> +1 if we also add:
>>> tryReadChan :: Chan a -> IO (Maybe a)
>>>
>>>> peekTChan :: TChan a -> STM a
>>>> tryPeekTChan :: TChan a -> STM (Maybe a)
>>>
>>> +1 if we also add:
>>> peekChan :: Chan a -> IO a
>>> tryPeekChan :: Chan a -> IO (Maybe a)
>>
>> Here's the last time 'tryReadChan' came up, for reference:
>> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/14596
>>
>> I feel like these sorts of operations are much easier to get right in STM.
>
> Agreed. I'm all for adding Chan versions to base if we can get the
> implementation/semantics right, but since I don't have experience with Chans
> I'm not sure if I'm the best person for that task.
The attached patch adds:
tryReadMVar :: MVar a -> IO (Maybe a)
tryReadChan :: Chan a -> IO (Maybe a)
peekChan :: Chan a -> IO a
tryPeekChan :: Chan a -> IO (Maybe a)
tryReadMVar and tryReadChan were taken from the patch from Mitar.
Thanks Antoine for linking that ticket.
Someone should definitely take a closer look at peekChan and
tryPeekChan and verify if they're correct.
Wren, something else: in the documentation of your new STM operations
you talk about "blocking". I think it's clearer and more consistent
with the rest of STM if you talk about "retrying" instead.
Regards,
Bas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: concurrent-mvar-chan-extras.dpatch
Type: application/octet-stream
Size: 75839 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110327/ca60f813/attachment-0001.obj>
More information about the Libraries
mailing list