octave-maintainers
[Top][All Lists]
Advanced

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

Re: [RFC] build with OpenMP by default?


From: Mike Miller
Subject: Re: [RFC] build with OpenMP by default?
Date: Tue, 22 Apr 2014 11:44:13 -0400

On Tue, Apr 22, 2014 at 17:28:42 +0200, Thomas Weber wrote:
> On Tue, Apr 22, 2014 at 09:31:11AM -0400, Mike Miller wrote:
>> Is it time to build Octave with OpenMP by default? It looks to me like
>> it's been an "experimental" disabled-by-default option since the 3.4.0
>> release. It has been enabled in Debian and Ubuntu builds since 3.4.3
>> was released in late 2011 and I'm not aware of any negative
>> consequences.
> It was enabled in Debian so that packages could use it:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631831

Thanks for that reference, and that's another good reason for enabling
it by default, as long as it doesn't hurt anything.

>> See bug #41699 [1] for my motivation for enabling OpenMP by default
>> (segfault when exiting or unloading oct-files that use OpenMP).
> Sorry, but I think that enabling OpenMP in Octave would just be hiding a
> problem here. If Octave unloads the OpenMP library while it is still in
> use by other threads, that is a bug. I don't have a suggestion on how to
> fix this, but linking the OpenMP library into Octave is a workaround, at
> best.

That's a fair point. And while this is a real problem, this isn't even
the fix for #41699 which might even be Windows-specific. It just
happens to be something I ran across while trying to reproduce that
bug.

Is there any general solution for dlopening a dynamic object, which
may or may not do some work with OpenMP, and possibly dlclosing it
later when finished with it? If the main program wasn't explicitly
linked with OpenMP, there appears to be nothing keeping it from being
unloaded while the thread pool is still running.

-- 
mike



reply via email to

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