Named pipes and multiple writers

I'll apologize in advance if something is not appropriate, but this is the first interaction with this project We (another open source project) have bumped into some problems using named pipes with multiple writers As far as I can see, reading through history, this have been a known issue for qui

Sv: Sv: Named pipes and multiple writers

>> [snip] As far as I can see, reading through history, this have been a known issue for quite some time, but it seems like there have been some attempts to solve it, e.g. in the branch topic/fifo (by Ken Brown) >> >> [snip] Does anyone have any knowledge about if this (topic

Sv: Sv: Sv: Named pipes and multiple writers

>On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote: >> On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote: >>> On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote: The ENIXIO occurs when parallel child-processes simultaneously using O_NONBLOCK opening the descriptor. >>> >>> This i

Sv: Sv: Sv: Sv: Named pipes and multiple writers

>On 3/27/2020 10:53 AM, sten.kristian.ivars...@gmail.com wrote: >>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote: On 3/26/2020 6:39 PM, Ken Brown via Cygwin wrote: > On 3/26/2020 6:01 PM, sten.kristian.ivars...@gmail.com wrote: >> The ENIXIO occurs when parallel child-processes sim

Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

>On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote: >> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote: >>> On 3/28/2020 8:10 AM, sten.kristian.ivars...@gmail.com wrote: > On 3/27/2020 10:53 AM, sten.kristian.ivars...@gmail.com wrote: >>> On 3/26/2020 7:19 PM, Ken Brown via Cygwin wrote:

Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

> On 3/31/2020 5:10 PM, sten.kristian.ivars...@gmail.com wrote: > >> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote: > >>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote: > On 3/28/2020 8:10 AM, sten.kristian.ivars...@gmail.com wrote: > >> On 3/27/2020 10:53 AM, sten.kristian.ivars..

Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

> On 3/31/2020 5:10 PM, sten.kristian.ivars...@gmail.com wrote: > >> On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote: > >>> On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote: > On 3/28/2020 8:10 AM, sten.kristian.ivars...@gmail.com wrote: > >> On 3/27/2020 10:53 AM, sten.kristian.ivars..

Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

> On 4/1/2020 4:52 AM, sten.kristian.ivars...@gmail.com wrote: > >> On 3/31/2020 5:10 PM, sten.kristian.ivars...@gmail.com wrote: > On 3/28/2020 10:19 PM, Ken Brown via Cygwin wrote: > > On 3/28/2020 11:43 AM, Ken Brown via Cygwin wrote: > >> On 3/28/2020 8:10 AM, sten.kristian.ivars..

Sv: Sv: Sv: Sv: Sv: Sv: Sv: Sv: Named pipes and multiple writers

> On 4/1/2020 2:34 PM, Ken Brown via Cygwin wrote: > > On 4/1/2020 1:14 PM, sten.kristian.ivars...@gmail.com wrote: > >>> On 4/1/2020 4:52 AM, sten.kristian.ivars...@gmail.com wrote: > > On 3/31/2020 5:10 PM, sten.kristian.ivars...@gmail.com wrote: > >>> On 3/28/2020 10:19 PM, Ken Brown via

open descriptor to named pipes sometimes fail

Opening a (second) descriptor for (blocking) write sometimes fail The provided test case sometimes succeed, but quite often fail with ENOENT (in various indexes) I haven't dug deeper to find the underlaying cause yet Have anyone experienced this before ? Kristian #include #include #include #

unlink does not remove named pipe

If you're creating a lot's of named pipes in main process and in children and then using unlink, some of the named pipe files are not removed from the file system and no error is issued, i.e. unlink doesn't return -1 Kristian -- Problem reports: https://cygwin.com/problems.html FAQ:

Sv: unlink does not remove named pipe

> Greetings, Kristian Ivarsson via Cygwin! > > > If you're creating a lot's of named pipes in main process and in > > children and then using unlink, some of the named pipe files are not > > removed from the file system and no error is issued, i.e. unlink > &g

open write descriptor on named pipe sometime results in ENOENT

Hey all We're trying to nail down some issues with using named pipes The issue we're getting is deterministic (ENXIO) but it is not this one, but we think this issue is worth reporting anyway We're using the branch topic/fifo The program explained in short is: - One main (parent) pipe tha

posix_spawnp creates ghost processes

Hi all We're having a rather complex application and have noticed a rather weird behaviour that I cannot find any information about We're using posix_spawnp and sometimes it creates extra "ghost-process(es)" non visible to cygwin (via e.g. process status (ps)) but visible to Windows (Task Manager

Sv: posix_spawnp creates ghost processes

> Greetings, Kristian Ivarsson via Cygwin! > > > We're having a rather complex application and have noticed a rather > > weird behaviour that I cannot find any information about > > > We're using posix_spawnp and sometimes it creates extra "ghost- >

ECONNABORTED and ECONNRESET on TCP socket using recv()

Hi all Have anyone experienced getting ECONNABORTED and ECONNRESET on local TCP socket when using recv() ? We have a fairly complex application where it, amongst others, spawns child processes (using posix_spawnp) This is a simplified scenario - parent performs socket() + bind() + listen() to

Sv: ECONNABORTED and ECONNRESET on TCP socket using recv()

> > Hi all > > > > Have anyone experienced getting ECONNABORTED and ECONNRESET on local > > TCP socket when using recv() ? > > > > > > We have a fairly complex application where it, amongst others, spawns > > child processes (using posix_spawnp) > > > > This is a simplified scenario > > > > - paren

Sv: ECONNABORTED and ECONNRESET on TCP socket using recv()

> > > Hi all > > > > > > Have anyone experienced getting ECONNABORTED and ECONNRESET on local > > > TCP socket when using recv() ? > > > > > > > > > We have a fairly complex application where it, amongst others, > > > spawns child processes (using posix_spawnp) > > > > > > This is a simplified scen

AF_UNIX/AF_LOCAL

Hey folks (probably Corinna more specifically) As far as I know the "unix domain socket implementation" is not really complete We tried it and it didn't work for our purposes (the symptoms were UDP-like, i.e. it seemed that some messages were lost along the way (or possibly ended up in the wrong

Sv: AF_UNIX/AF_LOCAL

> On Jun 2 14:46, Kristian Ivarsson via Cygwin wrote: > > Hey folks (probably Corinna more specifically) > > > > As far as I know the "unix domain socket implementation" is not really > > complete > > > > We tried it and it didn't work for

Using cygwin-dll with msvc-exe

Hi all Our task is to use an own cygwin-gcc-dll imported and used in a msvc-exe (64-bit-system) According to https://cygwin.com/faq.html#faq.programming.msvc-gcc-objects it seems like it would be possible by doing it like https://cygwin.com/cygwin-ug-net/dll.html The msvc-exe compiles and links

Sv: Using cygwin-dll with msvc-exe

[snip] > They have incompatible internal startup and runtime environments including > stuff like initialization, signal, and exit function handling > (cygwin/newlib/gcc vs > Windows/APIs/VC) although Cygwin can build Windows-loadable dlls and > Windows-runnable exes and call Windows (system) dlls

Sv: Using cygwin-dll with msvc-exe

[snip] > > ... > >$ /cygdrive/c/Repos/Trunk/Debug64/my_msvc_program.exe > > 0 [main] my_msvc_program (17392) child_copy: cygheap read > > copy failed, 0x180343408..0x18036E1D8, done 0, windows pid 17392, Win32 > error 6 > >582 [main] my_msvc_program (17392) > > C:\Repos\Trunk\

Limit for number of child processes

Dear cygwin folks It seems like there's a limit of the number of possible child processes defined to 256 with 'NPROCS' in //winsup/cygwin/child_info.h used in 'cprocs' in //winsup/cygwin/sigproc.cc 256 is quite few possible children in an enterprise environment and perhaps the limit should be lim

Sv: Limit for number of child processes

Hi Corinna > > Dear cygwin folks > > > > It seems like there's a limit of the number of possible child > > processes defined to 256 with 'NPROCS' in //winsup/cygwin/child_info.h > > used in 'cprocs' in //winsup/cygwin/sigproc.cc > > > > 256 is quite few possible children in an enterprise environme

Sv: Sv: Limit for number of child processes

> > Hi Corinna > > > >>> Dear cygwin folks > >>> > >>> It seems like there's a limit of the number of possible child > >>> processes defined to 256 with 'NPROCS' in > >>> //winsup/cygwin/child_info.h used in 'cprocs' in > >>> //winsup/cygwin/sigproc.cc > >>> > >>> 256 is quite few possible children

Sv: Sv: Sv: Limit for number of child processes

Hi all > > > > > > > It seems like there's a limit of the number of possible > > > > > > > child processes defined to 256 with 'NPROCS' in > > > > > > > //winsup/cygwin/child_info.h used in 'cprocs' in > > > > > > > //winsup/cygwin/sigproc.cc > > > > > > > > > > > > > > 256 is quite few possible c

TMP/TEMP environment variable and /tmp

Dear folks Does anyone know why cygwin annex the TMP (and TEMP) environment variable(s) and sets them to /tmp for cygwin-built-applications (executables) ? This results in that when you want the current users TMP-folder you end up with the /tmp path. As a result,when writing to that, without havi

Sv: TMP/TEMP environment variable and /tmp

> >>> Does anyone know the rational with this behaviour and what can be > >>> done to get hold of the (real) Windows TMP/TEMP > >>> environment-variable-values (in a > >>> (hopefully) platform independent way) ? > > >> so if you are making your custom tree, try to stick on that > >> expectation an

Re: TMP/TEMP environment variable and /tmp

>> Does anyone know the rational with this behaviour and what can be >> done to get hold of the (real) Windows TMP/TEMP >> environment-variable-values (in a >> (hopefully) platform independent way) ? > so if you are making your custom tree, try to stick on that > expectatio

Re: TMP/TEMP environment variable and /tmp

Does anyone know the rational with this behaviour and what can be done to get hold of the (real) Windows TMP/TEMP environment-variable-values (in a (hopefully) platform independent way) ? >>> so if you are making your custom tree, try to stick on that >>

Sv: TMP/TEMP environment variable and /tmp

Thanx all who helped out with this The reason to why we thought it worked in mysterious ways was a coincidence of how it worked in cygwin shell (due to /etc/profile etc) and that we didn't realize/investigate that the variable was NULL at this moment and that we fell back to our own default-val

g++ and c++17 filesystem

Hi folks The filesystem-library as a part of C++17 seems to have some defects and flaws in the cygwin-package and pretty much every lexical- and canonical operation works in mysterious ways (or not at all) Following output with g++cygwin $ uname -a CYGWIN_NT-10.0 JOKK 3.1.7(0.340/5/3) 2020-08

Sv: g++ and c++17 filesystem

> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: > > > The filesystem-library as a part of C++17 seems to have some defects > > and flaws in the cygwin-package and pretty much every lexical- and > > canonical operation works in mysterious ways (or not at

Re: g++ and c++17 filesystem

> 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin : > > On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: > >>>> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: >>> >>>> The filesystem-library as a part of C++17 seems to h

Re: g++ and c++17 filesystem

> I would agree that if you want an executable that acts and feels more like a > Windows native application, then mingw is probably what you want. Cygwin is > if you want something that acts and feels more like a Posix thing ... which > means it will be oriented to Posix style paths. To be ab

Sv: g++ and c++17 filesystem

> >> I would agree that if you want an executable that acts and feels more > like a Windows native application, then mingw is probably what you want. > Cygwin is if you want something that acts and feels more like a Posix > thing ... which means it will be oriented to Posix style paths. > > To be

Sv: g++ and c++17 filesystem

> > 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin : > > > > On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: > > > >>>> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: > >>> > >>>> The filesystem-library

Sv: Sv: g++ and c++17 filesystem

> Ok, first, I admit that I was not familiar with the details of > std::filesystem. However, after looking at it, I remain unsurprised that > the Cygwin and Mingw versions might be different. (I would also not be > surprised if there is a real bug in there.) At least semantic bugs considering th

Sv: Sv: g++ and c++17 filesystem

[snip] > >> As stated earlier, it seems like using mingw g++/libstdc++ (from the > >> cygwin-package-manager) it seems like it works better, but then you > >> can’t mix with other posix/cygwin mechanism (that uses cygstdc++) > >> without breaking ODR (and probably some memory models etc as well) so

Sv: Sv: Sv: g++ and c++17 filesystem

[snip] > > Applications might wanna extract type, name, parent-folder, etc but do > > rarely care about what kind of separator it has (/ or \) and the style > > of the root directory etc and it would be very neat if the cygwin > > std::filesystem-library became more agnostic in these regards > Not

Sv: Sv: Sv: Sv: g++ and c++17 filesystem

> On 11/23/20 8:35 AM, sten.kristian.ivars...@gmail.com wrote: > >> On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote: > >>>> that, for me, /c works.) Likewise, I would expect the normative > >>>> path separator to be / not \, and an absolute p

Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem

[snip] > std::filesystem POSIX mode is common to all POSIX platforms where > backslashes are NOT directory separators. How do you make them accept your > demands? How are you going to force POSIX platforms allow Windows specific > code? I've been trying to say over and over again that our code do

Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem

> > [snip] > > > >> std::filesystem POSIX mode is common to all POSIX platforms where > >> backslashes are NOT directory separators. How do you make them accept > >> your demands? How are you going to force POSIX platforms allow > >> Windows specific code? > > > > I've been trying to say over and o

Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem

> On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote: > > > all the std::filesystem implementations I've seen for Windows > > The implementation on top of Cygwin is not "for Windows", it's "for > Cygwin", i.e., "for Posix". An

Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem

> For the specific case C:\Temp, I found this: > > cygpath -ua 'C:\Temp' > >-> /cygdrive/c/Temp > > cygpath -ua /cygdrive/c/Temp > >-> /cygdrive/c/Temp > > cygpath -ua '\Temp' > >-> /cygdrive/c/Temp > > cygpath -ua '/Temp' > >-> /Temp > > Now Cygwin is open source, so you,

Sv: Sv: Sv: Sv: Sv: Sv: g++ and c++17 filesystem

Thanx for the insightful thoughts Ken See more below > >>> all the std::filesystem implementations I've seen for Windows > >> > >> The implementation on top of Cygwin is not "for Windows", it's "for > >> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to > do. > >> And that's w

Sv: g++ and c++17 filesystem

> >>> all the std::filesystem implementations I've seen for Windows > >> > >> The implementation on top of Cygwin is not "for Windows", it's "for > >> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to > do. > >> And that's where we keep talking at cross purposes. > > > Maybe it

Sv: Problems with native Unix domain sockets on Win 10/2019

Hi all Does anyone know the status of these fixes ? I saw an announcement for cygwin-3.2.0-0.1 that seemed to contain some AF_UNIX-related fixes but I fail to find out where that distribution exists (if it is supposed to be publicly accessible?), but I tried out the 2021-03-01 snapshot and perhap

Sv: Sv: Problems with native Unix domain sockets on Win 10/2019

[Snip] > >> Hi all > >> > >> Does anyone know the status of these fixes ? > >> > >> I saw an announcement for cygwin-3.2.0-0.1 that seemed to contain > >> some AF_UNIX-related fixes but I fail to find out where that > >> distribution exists (if it is supposed to be publicly accessible?), > >> but I

AF_UNIX/SOCK_DGRAM is dropping messages

Hi all Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to drop messages or at least they are not received in the same order they are sent Attached C:ish (with C++ threads though) sample program that essentially creates a "client" that writes as much as possible and a "server" that c

RE: AF_UNIX/SOCK_DGRAM is dropping messages

Hi Glenn Thanks for the reply, so more below > > Hi all > > > > Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to drop > > messages or at least they are not received in the same order they are sent > > > > Attached C:ish (with C++ threads though) sample program that essentially

RE: AF_UNIX/SOCK_DGRAM is dropping messages

[snip] > >>> Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to drop > >>> messages or at least they are not received in the same order they > >>> are sent [snip] > Thanks for the test case. I can confirm the problem. I'm not familiar enough > with the current AF_UNIX implementati

RE: AF_UNIX/SOCK_DGRAM is dropping messages

> >> Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems to > >> drop messages or at least they are not received in the same order > >> they are sent > >> > >> [snip] > >> > >>> Thanks for the test case. I can confirm the problem. I'm not > >>> familiar enough with the curre

RE: AF_UNIX/SOCK_DGRAM is dropping messages

> Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems > to > drop messages or at least they are not received in the same > order they are sent > > [snip] > > > Thanks for the test case. I can confirm the problem. I'm not > > familiar enou

RE: AF_UNIX/SOCK_DGRAM is dropping messages

> > Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems > > to > > drop messages or at least they are not received in the same > > order they are sent > > > > [snip] > > > > > Thanks for the test case. I can confirm the problem. I'm not > > >

RE: AF_UNIX/SOCK_DGRAM is dropping messages

Hi Ken > Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) seems > to > drop messages or at least they are not received in the same > order they are sent > > [snip] > > > Thanks for the test case. I can confirm the problem. I'm not > > famil

RE: AF_UNIX/SOCK_DGRAM is dropping messages

> >> Hi Ken > >> > >>> Using AF_UNIX/SOCK_DGRAM with current version (3.2.0) > seems > >>> to > >>> drop messages or at least they are not received in the same > >>> order they are sent > >>> > >>> [snip] > >>> > Thanks for the test case. I can confirm

RE: AF_UNIX/SOCK_DGRAM is dropping messages

[snip] > > I tried SOCK_STREAM (and SOCK_SEQPACKET I think) for CYGWIN 3.2.0 but > > that didn't work at all > > > > As far as I understand, both all types on pretty much all > > implementations preserves message ordering though > > > > I haven't tried SOCK_STREAM and/or SOCK_SEQPACKET with the >

RE: AF_UNIX/SOCK_DGRAM is dropping messages

> >> [snip] > >> > I tried SOCK_STREAM (and SOCK_SEQPACKET I think) for CYGWIN 3.2.0 > but that didn't work at all > > As far as I understand, both all types on pretty much all > implementations preserves message ordering though > > I haven't tried SOCK_STREAM and

RE: AF_UNIX/SOCK_DGRAM is dropping messages

[snip] > > I'm going to follow up on cygwin-developers. > > Great, I'll read about it there Does anyone know anything about the progress of this issue ? Best regards, Kristian > Keep up the good work > > Best regards, > Kristian > > > Ken -- Problem reports: https://cygwin.com/probl