This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: OpenBLAS patch for Cygwin

Hi, Sorry for the non-response. Been traveling for the last week and
not really checking this e-mail much.

On Tue, Feb 6, 2018 at 3:15 PM, Marco Atzeri wrote:
> On 06/02/2018 13:10, Erik Bray wrote:
>> Hello,
>> Users/maintainers of OpenBLAS on Cygwin may be interested in this
>> patch to improve support for fork():
>> Assuming this looks good (feedback welcome) it might be nice to have
>> this patch included in the next release of the official OpenBLAS
>> package for Cygwin since its incompatibility with fork() has caused
>> problems in the past [1].
>> Thanks,
>> E
>> [1]
> Noted.

And I see you just made a new package release incorporating my patch--thanks!

> Do you have a test case to show the failure with current build ?

The upstream pull request included such a test (the test had existed
previously in the code base but was disabled and never re-enabled in
the course of porting to a different testing framework).

> Any reason to use OS_CYGWIN_NT and not __CYGWIN__ in the patch ?

Normally I would just use __CYGWIN__ but this is following the
convention used throughout the rest of the OpenBLAS codebase.  It's
actually kind of nice that they have a consistent naming scheme for
platform macros.

On Tue, Feb 6, 2018 at 3:24 PM, Corinna Vinschen
<> wrote:
> Also, it should really use pthread functions and drop the notion that
> Cygwin is a Windows target.  Assuming you're running fork from another
> thread than the main thread, does it still work with native Windows
> threads?

I definitely agree in general. I'm going to experiment with a second
patch to just have it use pthreads on Cygwin. I can't think of any
reason it shouldn't work. Is there any particular extra overhead to
pthreads in Cygwin over using the native API directly?  AFAICT the
only slight additional overhead is in thread creation, but that's not
a problem.

I haven't tried forking from another thread. I don't think that should
make an enormous difference, but I'll make a test case to try that.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]