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