unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Panicz Maciej Godek <godek.maciek@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: [PATCH] Fix thread-unsafe lazy initializations
Date: Thu, 23 Jan 2014 16:22:31 -0500	[thread overview]
Message-ID: <87txcujsvc.fsf@netris.org> (raw)
In-Reply-To: <CAMFYt2aJ8e8obfpk=uyR6f8YYvL1k4YRd4awSjU8-sdshkUfKQ@mail.gmail.com> (Panicz Maciej Godek's message of "Thu, 23 Jan 2014 21:25:38 +0100")

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> 2014/1/23 Mark H Weaver <mhw@netris.org>:
>> This patch fixes all of the thread-unsafe lazy initializations I could
>> find in stable-2.0, using 'scm_i_pthread_once'.
>>
>> Any comments and/or objections?
>
> Does this fix the error that Chris Vine found some time ago?

Probably not, but who knows?  Would you like to try?

There are definitely still thread-safety problems with module
autoloading.  I haven't fixed those yet.

> If so, is there any test in the test suite that failed before, and
> doesn't fail anymore?

No.

> According to Ludovic, Chris' example corresponds to
> test-pthread-create-secondary.c -- yet they differ in that guile's
> test doesn't use scm_c_eval_string, which helped to reveal the
> problem.
> Shouldn't it be added to the test suite along with the patch, for regression?

It would be a lot of work to add tests for all of these fixes, and I'm
not sure it would be easy to write tests that would detect these
problems with reasonably high probability.

Anyway, I'm already overloaded with work to do.
Would you like to do it?

> Could we come up with any tests that would prove with certainty that
> there are still some failures caused by lazy intializations of
> modules?

I don't need such a test.  It's obvious from the code that module
autoloading is not thread safe.

    Regards,
      Mark



  reply	other threads:[~2014-01-23 21:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 17:54 [PATCH] Fix thread-unsafe lazy initializations Mark H Weaver
2014-01-23 20:25 ` Panicz Maciej Godek
2014-01-23 21:22   ` Mark H Weaver [this message]
2014-01-23 22:20     ` Panicz Maciej Godek
2014-01-24  4:04       ` Mark H Weaver
2014-01-24 15:52 ` Mark H Weaver
  -- strict thread matches above, loose matches on Subject: below --
2012-11-29 18:54 Thread-unsafe initialization problems in Guile Mark H Weaver
2012-11-29 20:05 ` Ludovic Courtès
2012-11-29 22:42   ` Mark H Weaver
2013-01-21 20:04     ` Andy Wingo
2013-01-23 17:50       ` Mark H Weaver
2013-01-23 18:25         ` Mark H Weaver
2013-02-28 21:07           ` Mark H Weaver
2013-02-28 23:20             ` [PATCH] Fix thread-unsafe lazy initializations Mark H Weaver
2013-03-01  9:23               ` Ludovic Courtès
2013-03-05 18:53                 ` Mark H Weaver
2013-03-05 20:45                   ` Ludovic Courtès
2013-03-05 21:10                     ` Mark H Weaver

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=87txcujsvc.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=godek.maciek@gmail.com \
    --cc=guile-devel@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).