From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Fix thread-unsafe lazy initializations Date: Thu, 23 Jan 2014 23:04:22 -0500 Message-ID: <87eh3yja9l.fsf@netris.org> References: <87ha8ulh1z.fsf@netris.org> <87txcujsvc.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390536451 24871 80.91.229.3 (24 Jan 2014 04:07:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2014 04:07:31 +0000 (UTC) Cc: guile-devel To: Panicz Maciej Godek Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 24 05:07:37 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W6Y3M-0000Pg-Ed for guile-devel@m.gmane.org; Fri, 24 Jan 2014 05:07:36 +0100 Original-Received: from localhost ([::1]:44288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Y3L-0006SJ-PG for guile-devel@m.gmane.org; Thu, 23 Jan 2014 23:07:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Y3A-0006S8-Bs for guile-devel@gnu.org; Thu, 23 Jan 2014 23:07:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6Y33-0008AX-2E for guile-devel@gnu.org; Thu, 23 Jan 2014 23:07:24 -0500 Original-Received: from world.peace.net ([96.39.62.75]:59463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Y32-0008AT-Uv for guile-devel@gnu.org; Thu, 23 Jan 2014 23:07:17 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1W6Y2p-0001Mv-2r; Thu, 23 Jan 2014 23:07:03 -0500 In-Reply-To: (Panicz Maciej Godek's message of "Thu, 23 Jan 2014 23:20:44 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16838 Archived-At: Panicz Maciej Godek writes: >>> 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? Here's what I should have written in response to the above: this will be a good thing to do when I have a patch to fix Chris' problem. However, that's not what this patch is. >> 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. > > But if you come up with some ideas, I'd be glad to hear them, and then > I could perhaps implement them. Maybe it would be a nice feature if > the "make check" instruction would generate a report that would gather > all the relevant information about the environment that could be sent > to some public address. I don't think such a thing belongs in "make check". I'm not even sure such a thing belongs in Guile. I think it belongs in a separate bug reporting tool. Such projects already exist, such as ABRT. The job is pretty much the same for any piece of software, so it shouldn't be reinvented in every piece of software. >>> 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. > > But they might prove good for the time when you progress with your > work to suspect that the issue is already solved :) Please, this is a discussion for another time. I asked for comments about the patch I just wrote. I didn't ask for suggestions for new jobs that I should do that are only vaguely related to the patch I just wrote. As I said, I'm overloaded enough as it is. Mark