unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
To: "Julian Graham" <joolean@gmail.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, guile-devel@gnu.org
Subject: Re: srfi-18 requirements
Date: Wed, 09 Apr 2008 22:29:38 +0100	[thread overview]
Message-ID: <87tziaogxp.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <2bc5f8210804031207s25be680aj99b50eaa1d66b6d7@mail.gmail.com> (Julian Graham's message of "Thu, 3 Apr 2008 15:07:16 -0400")

"Julian Graham" <joolean@gmail.com> 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





  reply	other threads:[~2008-04-09 21:29 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11  1:54 srfi-18 requirements Julian Graham
2007-10-12  8:42 ` Ludovic Courtès
2007-10-12 15:31   ` Julian Graham
2007-10-15 22:26     ` Julian Graham
2007-10-15 22:35       ` Stephen Compall
2007-10-15 22:47         ` Julian Graham
2007-10-29 14:37           ` Julian Graham
2007-11-26 18:11             ` Julian Graham
2007-11-27  9:14               ` Ludovic Courtès
2007-11-28 18:23             ` Ludovic Courtès
2007-11-28 18:55               ` Julian Graham
2007-12-01  5:08               ` Julian Graham
2007-12-01 10:21                 ` Ludovic Courtès
2007-12-02  3:59                   ` Julian Graham
2007-12-04 22:20                     ` Neil Jerram
2007-12-04 22:29                 ` Neil Jerram
2007-12-11  4:20                   ` Julian Graham
2007-12-18  4:30               ` Julian Graham
2007-12-28 18:46                 ` Ludovic Courtès
2007-12-28 19:08                   ` Julian Graham
2007-12-28 22:35                     ` Neil Jerram
2007-12-30 11:04                 ` Neil Jerram
2007-12-30 20:38                   ` Julian Graham
2008-01-01 19:09                     ` Neil Jerram
2008-01-04  5:01                       ` Julian Graham
2008-01-05  0:30                         ` Neil Jerram
2008-01-06 21:41                           ` Julian Graham
2008-01-08 23:11                             ` Neil Jerram
2008-01-11  2:39                               ` Julian Graham
2008-01-17  1:48                                 ` Neil Jerram
2008-01-19 20:10                                   ` Julian Graham
2008-01-23 22:46                                     ` Neil Jerram
2008-01-23 23:23                                       ` Julian Graham
2008-01-25  1:07                                         ` Neil Jerram
2008-01-25  1:38                                           ` Julian Graham
2008-01-28  2:06                                             ` Julian Graham
2008-02-03  0:30                                               ` Neil Jerram
2008-02-05  6:27                                                 ` Julian Graham
2008-02-07  1:23                                                   ` Neil Jerram
2008-02-07  3:06                                                     ` Julian Graham
2008-02-07 23:26                                                       ` Neil Jerram
2008-02-07 23:33                                                         ` Julian Graham
2008-02-07 23:38                                                     ` Neil Jerram
2008-02-08  0:04                                                       ` Julian Graham
2008-02-11  5:14                                                         ` Julian Graham
2008-02-19 22:48                                                           ` Neil Jerram
2008-02-20  2:10                                                             ` Julian Graham
2008-02-22  0:33                                                               ` Neil Jerram
2008-02-22  4:14                                                                 ` Julian Graham
2008-02-24  9:41                                                                   ` Neil Jerram
2008-02-24 18:17                                                                     ` Julian Graham
2008-02-24 23:29                                                                       ` Neil Jerram
2008-03-01 19:56                                                                         ` Julian Graham
2008-03-08 16:34                                                                           ` Neil Jerram
2008-03-11  4:02                                                                             ` Julian Graham
2008-03-22 18:55                                                                               ` Julian Graham
2008-03-23 23:57                                                                                 ` Neil Jerram
2008-03-24 22:03                                                                               ` Neil Jerram
2008-03-26 15:55                                                                                 ` Julian Graham
2008-04-03  0:18                                                                                   ` Neil Jerram
2008-04-03 19:07                                                                                     ` Julian Graham
2008-04-09 21:29                                                                                       ` Neil Jerram [this message]
2008-04-14  0:43                                                                                         ` Julian Graham
2008-05-14  1:23                                                                                           ` Julian Graham
2008-05-14 21:13                                                                                             ` Neil Jerram
2008-05-14 23:11                                                                                           ` Neil Jerram
2008-05-15  5:05                                                                                             ` Julian Graham
2008-05-24 11:42                                                                                               ` Neil Jerram
2008-05-24 13:55                                                                                                 ` Neil Jerram
2008-05-25  2:07                                                                                                 ` Julian Graham
2008-05-31 21:41                                                                                                 ` Ludovic Courtès
2008-06-02  4:48                                                                                                   ` Julian Graham
2008-06-21  5:03                                                                                                     ` Julian Graham
2008-06-30 17:51                                                                                                       ` Ludovic Courtès
2008-01-08 23:41                             ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tziaogxp.fsf@ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=guile-devel@gnu.org \
    --cc=joolean@gmail.com \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).