Re: srfi-18 requirements

[Julian Graham]

>  > My understanding based on our previous
>  > conversations is that we want core and SRFI-18 code to be able to
>  > co-exist as much as possible...)
>
>  I agree that we want co-existence in some sense, but I'm not sure that
>  sense extends to mixing core and SRFI-18 API calls for the same
>  mutex.  I'm struggling right now to explain exactly what I mean - but
>  my intuition is that the use case above is going beyond
>  reasonableness, and so we could reasonably say that the result of
>  mutex-state would be undefined in this case.

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.

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.


>  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.


Regards,
Julian