Re: srfi-18 requirements

[Julian Graham]

Hi Neil,


>  > No, we didn't, although I agree such a parameter would be pretty
>  > useful.
>
>  Well we discussed it a bit here:
>  http://lists.gnu.org/archive/html/guile-devel/2008-02/msg00004.html
>  http://lists.gnu.org/archive/html/guile-devel/2008-02/msg00005.html

Argh, don't know how I missed that.  Sorry!


>  So for the SRFI-18 API, timeout-val is sometimes absolute and
>  sometimes relative!  I guess that just means that the SRFI-18 Scheme
>  code will have to add (current-time), when an integer or float is
>  given to it.

Oops -- my mistaken again.  Yes, using `current-time' sounds like a good plan.


>  Sorry for missing this before.  The SRFI-18 semantics are really
>  interesting, but I think we need to preserve the existing semantics
>  too for back-compatibility.

Sure, fair enough.


>  I guess that means that scm_unlock_mutex_timed will need to take
>  another optional parameter (or two) indicating whether
>
>  - it is an error to unlock an unlocked mutex (default yes, but SRFI-18
>   will pass "no")
>
>  - it is an error to unlock a mutex owned by another thread (default
>   yes, SRFI-18 will pass "no").
>
>  Can you propose a representation for this?

Well, this could be down with an entirely separate primitive -- that
is, we could add something with a name like scm_make_permissive_mutex
that initializes the fat_mutex struct with a couple of new flags.
That wouldn't be strictly compatible with SRFI-18, since SRFI-18
`mutex-unlock!' accessing regular mutexes through Guile's primitives
could cause errors to be signaled, but it actually might make more
sense than passing flags to the unlock call, since I would think users
would want consistent behavior from their mutexes, no matter which
functions were used to manipulate them.

If this isn't acceptable, then I think one or two extra flags at the
end is okay.  We could justify one flag by using it to mean "unlock
the mutex, no matter who owns it, including no one."  Either way, the
syntax could be along the lines of unlock-mutex! mutex
[[[allow-unlocking-unowned]] [allow-unlocking-other-thread]].

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.


>  Is it possible to reorganize the relevant code a bit, so that
>  scm_unlock_mutex_timed (mx, cv, 0) does not lock and immediately
>  unlock the mutex after the cond var has been signalled?

Certainly.  It'll be in the next version of the patch.


Regards,
Julian