Re: srfi-18 requirements

[Neil Jerram <neil@ossau.uklinux.net>]

"Julian Graham" <joolean@gmail.com> 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