Re: srfi-18 requirements

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

"Julian Graham" <joolean@gmail.com> writes:

> As regards the changes below, I've attached a patch against the new
> HEAD that I think resolves the issues you mentioned.

Thanks, that's in CVS now.

>>  Finally, please note that we will need a NEWS entry for this work.
>>  Are you happy to write that too?  (You may of course prefer to defer
>>  this until the SRFI-18 Scheme parts are committed too - that's
>>  absolutely fine.)
>
> Yes, I'm happy to write the NEWS entry, but think I would like to wait
> to submit it until everything's in.

Absolutely fine.

>  And speaking of the Scheme parts,
> shall I go ahead and send you a patch that includes those?  I expect
> that my original implementation won't need that much tweaking to
> cooperate with the new core interfaces; it shouldn't take long.

Yes please!

> Speaking of which, though, I've already run into some difficulty
> implementing mutex-state -- the solution you proposed earlier depends
> on mutex-owner being visible to Scheme code (it's not, at the moment),
> and I can't figure out how to write mutex-state efficiently without it
> (or some other way of passively inspecting the mutex).  Any
> suggestions would be appreciated!

> [...] I think enabling scm_mutex_owner would allow me to proceed,
> but I don't want to un-ifdef it without knowing why it was disabled
> in the first place (the ChangeLogs don't shed any light on the
> matter).

I also see no problem - in API terms - with un-ifdefing
scm_mutex_owner (and scm_mutex_level, while we're there).  Could you
just review, though, whether you're happy with their implementation?
In particular, should these functions lock and unlock m->lock?

> (From a theoretical standpoint, I don't see a problem with the
> existence of something like scm_mutex_owner.  The man page for
> pthread_mutex_lock claims that it's not part of the pthreads spec
> because it could cause an unacceptable performance hit, but it's
> pretty clear from playing around with gdb that Linux's pthreads
> implementation stores the requisite information...)

But that's spec vs. implementation.  I'd tend to give the spec writers
the benefit of the doubt here, i.e. to assume that they had reasonable
implementations in mind where it would be a performance hit.

(And of course, the pthreads point/argument doesn't transfer in detail
across to Guile's API, because our mutexes offer a lot more features
than the base pthreads mutexes.)

> Regards,
> Julian

Regards,
        Neil