[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: srfi-18 requirements
From: |
Neil Jerram |
Subject: |
Re: srfi-18 requirements |
Date: |
Sun, 24 Feb 2008 23:29:01 +0000 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
"Julian Graham" <address@hidden> writes:
>> Agreed, that's a nice solution. The matter of whether a mutex can be
>> unlocked by another thread will depend on an application's design for
>> how it uses that mutex, and it feels right for the application to
>> declare this when the mutex is created, instead of on every unlock
>> call.
>>
>> On the Scheme level, I think the call can still be `make-mutex', with
>> optional flag args - is that right?
>
> Yes. For C, though, how do you want to manage passing these flags? I
> imagine the primitive should be named something like
> scm_make_mutex_with_options (or _with_flags), and we could either
> require two arguments (each being a symbol option as described below
> or SCM_UNDEFINED) or have it take a list containing an arbitrary
> number of symbol options to allow us to extend its behavior as
> necessary. I didn't get a strong sense of established precedent
> looking at Guile's C API; I'm kind of leaning towards the list
> approach right now.
That sounds great.
>> > Actually, I just remembered a fairly elegant approach that seems to be
>> > used in other parts of the Guile API -- these optional arguments could
>> > be specified as symbols: 'unlock-if-unowned and
>> > 'unlock-if-owned-by-other, say. Let me know what you'd prefer.
>>
>> This is still an interesting question, but now for `make-mutex'
>> instead of for `unlock-mutex'. Personally I like the symbol approach,
>> because (in comparison with a sequence of #t and #f) it will make the
>> code easier to understand at the point of the call, and also because
>> the #t/#f approach requires remembering the parameter ordering.
>
> Cool -- I'll set up make-mutex for Scheme, and for C as described
> above. Let me know if that's not okay.
All sounds perfect to me.
Regards,
Neil
- Re: srfi-18 requirements, (continued)
- Re: srfi-18 requirements, Julian Graham, 2008/02/07
- Re: srfi-18 requirements, Neil Jerram, 2008/02/07
- Re: srfi-18 requirements, Julian Graham, 2008/02/07
- Re: srfi-18 requirements, Julian Graham, 2008/02/11
- Re: srfi-18 requirements, Neil Jerram, 2008/02/19
- Re: srfi-18 requirements, Julian Graham, 2008/02/19
- Re: srfi-18 requirements, Neil Jerram, 2008/02/21
- Re: srfi-18 requirements, Julian Graham, 2008/02/21
- Re: srfi-18 requirements, Neil Jerram, 2008/02/24
- Re: srfi-18 requirements, Julian Graham, 2008/02/24
- Re: srfi-18 requirements,
Neil Jerram <=