Ping^2.
On Tue, Oct 28, 2014 at 6:17 PM, Nathaniel Smith wrote:
> Ping.
>
> On 19 Oct 2014 23:44, "Nathaniel Smith" wrote:
>>
>> Hi Jakub,
>>
>> Thanks for your feedback! See below.
>>
>> On Thu, Oct 16, 2014 at 4:52 PM, Jakub Jelinek wrote:
>> > On Mon, Oct 13, 2014 at 10:16:19PM +0100, Nathan
Hi Jakub,
Thanks for your feedback! See below.
On Thu, Oct 16, 2014 at 4:52 PM, Jakub Jelinek 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 again.
>>
>>
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, es
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 wrote:
> Hi a
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 suppor
On Tue, Mar 4, 2014 at 11:37 PM, Nathaniel Smith wrote:
> On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson 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
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson 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. Consider these t
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 chil
On Fri, Feb 14, 2014 at 3:43 AM, Jakub Jelinek 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 could be to
On Fri, Feb 14, 2014 at 3:14 PM, Richard Henderson 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 callback.
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
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?)
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_ru
> +/* 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.
> +gomp_afte
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 wo
16 matches
Mail list logo
