"Julian Graham" <[EMAIL PROTECTED]> writes:
> Were we to go this route (i.e., non-coexistence), I think the best
> solution would be something along the lines of the divide between
> Guile's built-in hash tables and SRFI-69 hash tables -- that is,
> obvious incompatibility based on data type. But that seems like an
> awful lot of work and a potential loss in terms of flexibility for
> developers.
I agree; so overall, it seems clear that we don't want to take this
route.
> With regard to supporting locked/not-owned:
>
>
>> 1. Calling lock-mutex with a thread parameter different from the
>> calling thread, and which isn't #f. I believe this should be a core
>> feature (as well as a SRFI-18 one), and it had completely escaped my
>> notice that this detail had evaporated from your patches. I believe
>> you implemented this originally, then removed it following my attempt
>> to draw a line between core stuff and SRFI-18 stuff - so I guess you
>> thought that was one of the implications of what I wrote; sorry about
>> that. Would it be easy at this point to reinstate this?
>
> That was my assumption, yes. Sorry! I can certainly reinstate, and
> will do so in the next patch I submit. While we're discussing this,
> though, any design issues you'd like to consider? E.g., this might
> not be something we'd want every mutex to support, so we could add a
> flag to make-mutex, a la the earlier stuff for external unlocking.
I think it depends whether we see the existing make-mutex flags as a
policing thing or as a trying-to-be-helpful-at-runtime thing. My view
is that they are mostly trying to be helpful, specifically to catch
the bugs where a developer who is expecting traditional mutex
behaviour accidentally calls unlock-mutex from the wrong thread, or on
a mutex that isn't locked. In addition, there is the possibility that
some existing code might be relying on exceptions being raised in
these cases.
The (lock-mutex ... thread) case feels to me to be quite different
from this, because the (lock-mutex ...) call that a developer has to
write, in order to take advantage of the SRFI-18 features, is
different at the source code level: to get the SRFI-18 behaviour, the
developer has to explicitly supply the optional thread parameter.
This makes it impossible (or as near impossible as we care about) that
a developer would get the SRFI-18 behaviour by mistake; and existing
code (which cannot specify the thread parameter, because it isn't
supported yet!) will automatically continue to get the traditional
behaviour.
Therefore I don't see the same kind of need for a make-mutex flag
here, as there was for the unlock cases.
>> 2. Calling lock-mutex with thread parameter #f, such as to produce the
>> SRFI-18 locked/not-owned state. My previous pure Scheme suggestion
>> for locked/not-owned was based on my statement that:
>
> ...
>
>> In terms of the C/Scheme boundary, one possible representation of this
>> would be to introduce a mutex-locked? primitive, which is significant
>> when mutex-owner returns #f, and distinguishes between the normal
>> unlocked state and locked/not-owned.
>
> ...
>
>> What do you think?
>
> I think that's quite elegant, actually. On initial consideration I
> was going to suggest that we bring back the use of SCM_UNSPECIFIED in
> the context of mutex ownership (that is, fat_mutex.owner can be
> SCM_UNSPECIFIED, #f, or a thread) that I'd removed in the final
> version of my patch -- after all, mutex-owner is for all intents and
> purposes new to the API, so we've got some freedom in how it's
> defined. ...But I think I prefer the solution you describe above,
> since it has the additional benefit of exposing only as much
> information about mutex state as a caller is interested in. So I'll
> go with that, I think, and send you a new patch for the core that
> incorporates all of this. Let me know if that's not okay.
Sounds good to me!
Regards,
Neil
