guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix thread-unsafe lazy initializations


From: Panicz Maciej Godek
Subject: Re: [PATCH] Fix thread-unsafe lazy initializations
Date: Thu, 23 Jan 2014 23:20:44 +0100

2014/1/23 Mark H Weaver <address@hidden>:
>> Does this fix the error that Chris Vine found some time ago?
>
> Probably not, but who knows?  Would you like to try?

Sure, but it will take some time, because I have to set up the build
environment first. I think I'll have it by tomorrow, if that's ok.

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

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. That way we could increase the probability of
detecting various problems (especially those that appear randomly).
However, it would be a more serious enterprise, and I'd need some more
time than I have now to do it.

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

If it comes to regression test, I think I can handle it (and if I
don't, then I'll ask for some support). If it comes to other tests,
then I think that I'd need more guidance.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]