Ping^2.
On Tue, Oct 28, 2014 at 6:17 PM, Nathaniel Smith n...@pobox.com wrote:
Ping.
On 19 Oct 2014 23:44, Nathaniel Smith n...@pobox.com wrote:
Hi Jakub,
Thanks for your feedback! See below.
On Thu, Oct 16, 2014 at 4:52 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Oct 13, 2014 at
Hi Jakub,
Thanks for your feedback! See below.
On Thu, Oct 16, 2014 at 4:52 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Oct 13, 2014 at 10:16:19PM +0100, Nathaniel Smith wrote:
Got total silence the last 4 times I posted this, and users have been
bugging me about it offline, so trying
On Mon, Oct 13, 2014 at 10:16:19PM +0100, Nathaniel Smith wrote:
Got total silence the last 4 times I posted this, and users have been
bugging me about it offline, so trying again.
This patch fixes a showstopper problem preventing the transparent use
of OpenMP in scientific libraries, esp.
Hi all,
Got total silence the last 4 times I posted this, and users have been
bugging me about it offline, so trying again.
This patch fixes a showstopper problem preventing the transparent use
of OpenMP in scientific libraries, esp. with Python. Specifically, it
is currently not possible to use
Hi all,
Ping. Again, this patch fixes a limitation in GOMP which makes it
impossible for programmers who care about gcc compatibility to safely
use OpenMP in libraries; GOMP is the last OpenMP implementation with
this limitation.
-n
On Wed, May 14, 2014 at 3:47 PM, Nathaniel Smith
Hi all,
Pinging again about the patch below. The lack of this patch is
essentially a blocker to using gcc+python+openmp together, which is a
shame, since python is increasingly important in numerical computing,
openmp is pretty useful, and gcc is the only openmp implementation
that does not
On Tue, Mar 4, 2014 at 11:37 PM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson r...@redhat.com wrote:
On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
Yes, but the problem is that depending on what the user intends to do
after forking, our
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson r...@redhat.com wrote:
On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
Yes, but the problem is that depending on what the user intends to do
after forking, our pthread_atfork handler might help or it might hurt,
and we don't know which.
On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
Yes, but the problem is that depending on what the user intends to do
after forking, our pthread_atfork handler might help or it might hurt,
and we don't know which. Consider these two cases:
- fork+exec
- fork+continue to use OMP in child
On Fri, Feb 14, 2014 at 3:14 PM, Richard Henderson r...@redhat.com wrote:
On 02/14/2014 12:21 AM, Jakub Jelinek wrote:
Any reason not to just run gomp_free_thread_pool from
gomp_after_fork_callback
directly? I see no restrictions on what kind of code is allowed to execute
during that
On Fri, Feb 14, 2014 at 3:43 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Feb 14, 2014 at 09:21:24AM +0100, Jakub Jelinek wrote:
Well, fork is async signal safe function, so calling malloc/free, or any
kind of synchronization primitives is completely unsafe there.
The only safe thing
On Thu, Feb 13, 2014 at 01:22:41PM -0800, Richard Henderson wrote:
+/* This is to enable best-effort cleanup after fork. */
+static int gomp_we_are_forked = 0;
bool, no explicit initialization, possible removal, see below.
+static void
+gomp_free_thread_pool (int threads_running)
On Fri, Feb 14, 2014 at 09:21:24AM +0100, Jakub Jelinek wrote:
Well, fork is async signal safe function, so calling malloc/free, or any
kind of synchronization primitives is completely unsafe there.
The only safe thing could be to atomically or in some global flag (or set
some TLS flag?) and
On 02/14/2014 12:21 AM, Jakub Jelinek wrote:
Any reason not to just run gomp_free_thread_pool from
gomp_after_fork_callback
directly? I see no restrictions on what kind of code is allowed to execute
during that callback.
Well, fork is async signal safe function, so calling malloc/free, or
+/* This is to enable best-effort cleanup after fork. */
+static int gomp_we_are_forked = 0;
bool, no explicit initialization, possible removal, see below.
+static void
+gomp_free_thread_pool (int threads_running)
bool for threads_running. It looks like a count otherwise.
Problem: A common use care for OMP is to accelerate the internal
workings of an otherwise serial interface. For example, OpenBLAS in
some settings will internally use OMP to accelerate the implementation
of matrix-matrix multiply (DGEMM). When DGEMM is called, then an OMP
section is started, the
16 matches
Mail list logo
