[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:
> >> [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
[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
>
> >> 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
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
> >
> > 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
> >
> 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
> >> 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
[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
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
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
[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
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
> >>> 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
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
> 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,
> 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". And for Cygw
> > [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
[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
> 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
[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
>
[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)
> 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
> > 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-libr
> >> 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
> 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
> 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
> 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
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)
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
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
>> 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
>
> >>> 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
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
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
> > 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
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
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
[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)
> >
[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
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
> 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
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
> > > 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
> > 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
> >
> > -
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
> 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-
> process(
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
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
> 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
> > do
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:
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
> 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
> 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,
> 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,
> 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,
>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:
>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
>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
>> [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
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
61 matches
Mail list logo
