Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount

Andrey Repin wrote: I would argue against all junctions being treated blindly. The difference with bind mounts in Linux is that in Linux you don't have the information available within the filesystem itself, and have no other option, than to treat them as regular directories. Only direct

Re: fork() fails if it is called recursively from a child thread.

Takashi Yano writes: > 0 [main] a 4668 fork: child -1 - forked process 8456 died unexpectedly, > retry 0, exit code 0xC142, errno 11 Not sure if that helps, but that error says that some DLL could not be initialized. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb

Re: pthread_create() slowdown with concurrent sched_yield()

On Mar 8 18:00, Dan Bonachea wrote: > On Wed, Mar 8, 2017 at 11:48 AM, Corinna Vinschen > wrote: > > > > Thanks for the thorough analysis and especially the testcase! > > > > I applied a fix for this problem and uploaded new developer snapshots > > to

Re: fork() fails if it is called recursively from a child thread.

Thanks for your reply. On Thu, 09 Mar 2017 18:06:44 +0100 Achim Gratz wrote: > Takashi Yano writes: > > 0 [main] a 4668 fork: child -1 - forked process 8456 died > > unexpectedly, retry 0, exit code 0xC142, errno 11 > > Not sure if that helps, but that error says that some DLL could

Re: fork() fails if it is called recursively from a child thread.

On Thu, 9 Mar 2017 08:53:19 -0500 Eliot Moss wrote: Thank you for response. > This strikes me as either BLODA (interfering software) or a need to > rebase some dll(s). That's what I most commonly see that causes that > fork error. This occurs even under newly installed windows 10 & 7.

Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount

On Mar 9 07:48, L A Walsh wrote: > Andrey Repin wrote: > > I would argue against all junctions being treated blindly. > > The difference with bind mounts in Linux is that in Linux you don't have > > the > > information available within the filesystem itself, and have no other > > option, > > than

Re: fork() fails if it is called recursively from a child thread.

On 3/9/2017 12:33 PM, Takashi Yano wrote: > Thanks for your reply. > > On Thu, 09 Mar 2017 18:06:44 +0100 Achim Gratz wrote: > >> Takashi Yano writes: >>> 0 [main] a 4668 fork: child -1 - forked process 8456 died >>> unexpectedly, retry 0, exit code 0xC142, errno 11 >> >> Not sure if

Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount

Corinna Vinschen wrote: He's right. The mount point handling in Cygwin is based on the in-memory mount table. I'm not wanting a mount point fake. Just wanting it to look like a normal dir just like the mountvol-junctions. There's no reasonable way to fake some reparse point to look

Re: Strange errors running gcc tests on Cygwin

First of all, thank you for your response! On 03/08/2017 02:21 AM, Brian Inglis wrote: After any Windows Update, or a lot of package installs, you may want look at running rebase-trigger full[rebase] before rebooting to remove all Cygwin and Windows processes, then (with no Cygwin

bash -l not sourcing /etc/profile? (minor annoyance)

This is just a minor annoyance. When I start a mintty session and even if I type bash -l or basy -li, I don't get my /etc/profile sourced and I have to manually do it each time I log in. Any idea what's causing that? Possibly related, sshd doesn't seem to be reading my

Re: bash -l not sourcing /etc/profile? (minor annoyance)

On 2017-03-09 15:58, Daniel Santos wrote: > This is just a minor annoyance. When I start a mintty session and > even if I type bash -l or basy -li, I don't get my /etc/profile > sourced and I have to manually do it each time I log in. Any idea > what's causing that? Cygwin/bash/mintty shortcut

Re: Strange errors running gcc tests on Cygwin

On 2017-03-09 15:53, Daniel Santos wrote: > First of all, thank you for your response! > > On 03/08/2017 02:21 AM, Brian Inglis wrote: >> After any Windows Update, or a lot of package installs, you may want >> look at running >> rebase-trigger full[rebase] >> before rebooting to remove all

Re: Strange errors running gcc tests on Cygwin

On 3/9/2017 6:51 PM, Brian Inglis wrote: > On 2017-03-09 15:53, Daniel Santos wrote: > >>> If you are running a lot of Cygwin services, cron or Scheduled Tasks, >>> and/or background processes, you may want to look at running cygserver >>> to cache process info and common system info (including

RE.(cygwin@cygwin.com)

I will like to discuss a partnership deal with you. Please allow me give you a brief picture of what I have in mind by replying to this mail; Best Regards, Zan Chang -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

fork() fails if it is called recursively from a child thread.

Hello, I found fork() fails if it is called recursively from a child thread. Simple test case, attached (fk.c), reproduces this problem. Expected result: Parent 0 [22034] exit. Child 0 [22036] works. Parent 1 [22036] exit. Child 1 [22038] works. Parent 2 [22038] exit. Child 2 [22039] works.

Re: fork() fails if it is called recursively from a child thread.

On 3/9/2017 6:39 AM, Takashi Yano wrote: > Hello, > > I found fork() fails if it is called recursively from a child thread. > > Simple test case, attached (fk.c), reproduces this problem. > > Expected result: > Parent 0 [22034] exit. > Child 0 [22036] works. > Parent 1 [22036] exit. > Child 1

Re: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount

Greetings, L. A. Walsh! > Didn't see a response to this, so reposting, as this > would provide a needed vol and subdir mount facility as > exists on linux... > Especially, since there was a misunderstanding of what > was needed or wanted w/regards to the JUNCTION file-system > mounts in Windows.