Re: AF_UNIX/SOCK_DGRAM is dropping messages
On 2021/04/01 6:02 pm, Ken Brown via Cygwin wrote: Here's the issue, briefly. The communication is done via a Windows named pipe. The receiver creates the pipe when it creates and binds its socket. It creates only one pipe instance. The sender connects to the pipe, writes, and closes its handle. But the pipe is not available for another sender to connect to until the receiver reads the message, after which it disconnects the sender. This https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipe-instances seems to indicate that multiple pipe instances are needed to handle multiple clients nicely - it also has sample code for such. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
python3-odf-1.4.1-1.tar.xz corrupt on all mirrors
Hi All, the mentioned package file is corrupt on all mirrors I tested. Please, check and correct. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: 3270
On Tue, Mar 23, 2021 at 4:51 AM Peter A. wrote: > > On Sun, Mar 21, 2021 at 06:51:05PM +0100, Cygwin List wrote: > > Hi, > > > > Do we have any c/s/x3270 maintainer? > > Do we have any c/s/x3270 users except me? > > That would be me. I haven't had much time to try and package a new > x3270. Also, the source package has changed form in such a way that I > need to change how it's built entirely. > So, if you have some problems with the current version let me know and > I'll try and help. It could just need to be built against latest > Cygwin. I need a new feature in version 4.1alpha7 (Double-clicking on a URL in x3270 (on most platforms) and in wc3270 now opens that link in the browser). Currently I am running wc3270 (native windows) because with that one I can configure Right-Ctrl to be ENTER, and as I understand I can't do that in c3270 (cygwin). Maybe I should just stick with wc3270. > > > /Morten > > -- > > Problem reports: https://cygwin.com/problems.html > > FAQ: https://cygwin.com/faq/ > > Documentation:https://cygwin.com/docs.html > > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: python3-odf-1.4.1-1.tar.xz corrupt on all mirrors
On 06.04.2021 11:48, Rainer Emrich wrote: Hi All, the mentioned package file is corrupt on all mirrors I tested. Please, check and correct. python3-odf-1.4.1-1.tar.xz is an empty archive $ ls -l python3-odf-1.4.1-1.tar.xz -rwxrwxr-x+ 1 Marco Kein 108 Apr 6 12:38 python3-odf-1.4.1-1.tar.xz $ sha512sum python3-odf-1.4.1-1.tar.xz da016ecd9ac6dd3ecd1a65b80c2728db59bccd9ca5e6b54888f02398e3f97a90d1bae3bef85f0eb0950c07734bf3e191fb679fc39527205ba0520009ca4769d2 *python3-odf-1.4.1-1.tar.xz and that match with the content of setup.ini install: x86_64/release/python-odf/python3-odf/python3-odf-1.4.1-1.tar.xz 108 da016ecd9ac6dd3ecd1a65b80c2728db59bccd9ca5e6b54888f02398e3f97a90d1bae3bef85f0eb0950c07734bf3e191fb679fc39527205ba0520009ca4769d2 try cleaning your setup cache -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Advertising inquiry to cygwin.com
Hi! I’m an SEO manager . I browsed your website and should say that I like it – both the style and content you post. I’m writing to ask about some advert opportunities and offers you have. I’m greatly interested in • guest posts • link insertion (in the existing article) • homepage link placement • banners Could you, please, provide prices for these kinds of advertising? I’m interested in permanent placement as well as per month. If you can offer other online platforms for advertising, I will consider them with pleasure. Thank you in advance! -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
IBM MQ client application fails on latest cygwin
Hi, Came back from easter vacation today and updated my cygwin installation. I havn't touched my PC since March 26. I have a non-cygwin IBM MQSeries client application which I call from a script. It connects to my z/OS MQ server. When I run it from a windows command prompt, it works fine. When I run it from mintty, it fails in a strange way. On my PC I see 2539 (09EB) (RC2539): MQRC_CHANNEL_CONFIG_ERROR On z/OS I see CSQX575E QMGR CSQXRESP Negotiation failed for channel CSQX228E QMGR CSQXRESP Listener unable to start channel, channel TRPTYPE=TCP INDISP=QMGR So it seems some garbage has been sent. Installing old versions of mintty gives the same result. Installing an old version of cygwin seems to resolve the issue: 3.2.0-1 fail 3.1.7-1 fine How can I help? /Morten -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: IBM MQ client application fails on latest cygwin
On Tue, 6 Apr 2021 15:16:56 +0200 Morten Kjærulff wrote: > I have a non-cygwin IBM MQSeries client application which I call from > a script. It connects to my z/OS MQ server. > > When I run it from a windows command prompt, it works fine. > > When I run it from mintty, it fails in a strange way. > On my PC I see > 2539 (09EB) (RC2539): MQRC_CHANNEL_CONFIG_ERROR > On z/OS I see > CSQX575E QMGR CSQXRESP Negotiation failed for channel > CSQX228E QMGR CSQXRESP Listener unable to start channel, > channel > TRPTYPE=TCP INDISP=QMGR > So it seems some garbage has been sent. > > Installing old versions of mintty gives the same result. > > Installing an old version of cygwin seems to resolve the issue: > 3.2.0-1 fail > 3.1.7-1 fine > > How can I help? Could you please try the followings and let me know the results? 1) Execute 'cmd /c bash' in mintty and run MQ clint. 2) Run cygwin in command prompt and execute 'script', then run MQ client. -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: IBM MQ client application fails on latest cygwin
On Tue, 6 Apr 2021 15:16:56 +0200 Morten Kjærulff wrote: > When I run it from a windows command prompt, it works fine. In this case, did you run MQ client from cygwin shell in command prompt? Or run it in cmd.exe? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 current AF_UNIX implementation to debug
> >>> this easily. I'd rather spend my time on the new implementation (on
> >>> the topic/af_unix branch). It turns out that your test case fails
> >>> there too, but in a completely different way, due to a bug in sendto
> >>> for datagrams. I'll see if I can fix that bug and then try again.
> >>>
> >>> Ken
> >>
> >> Ok, too bad it wasn't our own code base but good that the "mystery"
> >> is verified
> >>
> >> I finally succeed to build topic/af_unix (after finding out what
> >> version of zlib was needed), but not with -D__WITH_AF_UNIX to
> >> CXXFLAGS though and thus I haven’t tested it yet
> >>
> >> Is it sufficient to add the define to the "main" Makefile or do you
> >> have to add it to all the Makefile:s ? I guess I can find out though
> >
> > I do it on the configure line, like this:
> >
> > ../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --prefix=...
> >
> >> Is topic/af_unix fairly up to date with master branch ?
> >
> > Yes, I periodically cherry-pick commits from master to topic/af_unix.
> > I'lldo that again right now.
> >
> >> Either way, I'll be glad to help out testing topic/af_unix
> >
> > Thanks!
>
> I've now pushed a fix for that sendto bug, and your test case runs without
> error on the topic/af_unix branch.
It seems like the test-case do work now with topic/af_unix in blocking mode,
but when using non-blocking (with MSG_DONTWAIT) there are some issues I think
1. When the queue is empty with non-blocking recv(), errno is set to EPIPE but
I think it should be EAGAIN (or maybe the pipe is getting broken for real of
some reason ?)
2. When using non-blocking recv() and no message is written at all, it seems
like recv() blocks forever
3. Using non-blocking recv() where the "client" does send less than "count"
messages, sometimes recv() blocks forever (as well)
My naïve analysis of this is that for the first issue (if any) the wrong errno
is set and for the second issue it blocks if no sendto() is done after the
first recv(), i.e. nothing kicks the "reader thread" in the butt to realise the
queue is empty. It is not super clear though what POSIX says about creating
blocking descriptors and then using non-blocking-flags with recv(), but this
works in Linux any way
Let me know if I should provide more a specific explanation, but I think minor
modifications of the test-case can provoke all behaviours. I think 2 and 3 are
of the same reason though (as described above)
> By the way, I think the implementation of sendto/recv for datagrams is very
> inefficient when there are repeated calls to sendto as in your test case.
> Nevertheless, your test case actually runs slightly faster on the
> topic/af_unix
> branch than it does on master (when the latter succeeds, which it does about
> half the time for me). So I'm not sure whether it's worth worrying about
> this.
Of course we would like the best throughput possible 😉
> Here's the issue, briefly. The communication is done via a Windows named
> pipe.
> The receiver creates the pipe when it creates and binds its socket. It
> creates
> only one pipe instance. The sender connects to the pipe, writes, and closes
> its
> handle. But the pipe is not available for another sender to connect to until
> the
> receiver reads the message, after which it disconnects the sender.
Ok, in our application we will use long lived descriptors and multiple writers
that possible send large business messages (chunked into some smaller pieces
per sendto()/recv())
> Ken[Kristian]
Best regards,
Kristian
#include
#include
#undef AF_UNIX
#define AF_UNIX 31
#include
#include
#include
#include
#include
#include
// $ g++ --std=gnu++17 af_unix.cpp
const char* const path = "address";
const int count = 1;
const int size = BUFSIZ * 8;
int client()
{
const int fd = socket( AF_UNIX, SOCK_DGRAM, 0);
if( fd == -1)
{
perror( "socket error");
return -1;
}
struct sockaddr_un address{};
strcpy( address.sun_path, path);
address.sun_family = AF_UNIX;
char buffer[size] = {};
for( int idx = 0; idx < 100; ++idx)
{
memcpy( buffer, &idx, sizeof idx);
const ssize_t result = sendto( fd, buffer, size, 0, (struct
sockaddr*)&address, sizeof address);
// Assume the whole chunk can be sent
if( result != size)
{
perror( "sendto error");
return -1;
}
}
close( fd);
return 0;
}
int server()
{
const int fd = socket( AF_UNIX, SOCK_DGRAM, 0);
if( fd == -1)
{
perror( "socket error");
return -1;
}
struct sockaddr_un address{};
Re: AF_UNIX/SOCK_DGRAM is dropping messages
On 4/6/2021 3:52 AM, Noel Grandin wrote: On 2021/04/01 6:02 pm, Ken Brown via Cygwin wrote: Here's the issue, briefly. The communication is done via a Windows named pipe. The receiver creates the pipe when it creates and binds its socket. It creates only one pipe instance. The sender connects to the pipe, writes, and closes its handle. But the pipe is not available for another sender to connect to until the receiver reads the message, after which it disconnects the sender. This https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipe-instances seems to indicate that multiple pipe instances are needed to handle multiple clients nicely - it also has sample code for such. Yes, we do that for stream sockets that are listening. Whenever there's a connection, a new pipe instance is created so that the listening socket can continue listening. But I don't see an easy way to adapt this to datagram sockets, and I'm not even sure it's appropriate in that case. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: AF_UNIX/SOCK_DGRAM is dropping messages
On 4/6/2021 10:50 AM, sten.kristian.ivars...@gmail.com wrote: 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 implementation to debug this easily. I'd rather spend my time on the new implementation (on the topic/af_unix branch). It turns out that your test case fails there too, but in a completely different way, due to a bug in sendto for datagrams. I'll see if I can fix that bug and then try again. Ken Ok, too bad it wasn't our own code base but good that the "mystery" is verified I finally succeed to build topic/af_unix (after finding out what version of zlib was needed), but not with -D__WITH_AF_UNIX to CXXFLAGS though and thus I haven’t tested it yet Is it sufficient to add the define to the "main" Makefile or do you have to add it to all the Makefile:s ? I guess I can find out though I do it on the configure line, like this: ../af_unix/configure CXXFLAGS="-g -O0 -D__WITH_AF_UNIX" --prefix=... Is topic/af_unix fairly up to date with master branch ? Yes, I periodically cherry-pick commits from master to topic/af_unix. I'lldo that again right now. Either way, I'll be glad to help out testing topic/af_unix Thanks! I've now pushed a fix for that sendto bug, and your test case runs without error on the topic/af_unix branch. It seems like the test-case do work now with topic/af_unix in blocking mode, but when using non-blocking (with MSG_DONTWAIT) there are some issues I think 1. When the queue is empty with non-blocking recv(), errno is set to EPIPE but I think it should be EAGAIN (or maybe the pipe is getting broken for real of some reason ?) 2. When using non-blocking recv() and no message is written at all, it seems like recv() blocks forever 3. Using non-blocking recv() where the "client" does send less than "count" messages, sometimes recv() blocks forever (as well) My naïve analysis of this is that for the first issue (if any) the wrong errno is set and for the second issue it blocks if no sendto() is done after the first recv(), i.e. nothing kicks the "reader thread" in the butt to realise the queue is empty. It is not super clear though what POSIX says about creating blocking descriptors and then using non-blocking-flags with recv(), but this works in Linux any way Let me know if I should provide more a specific explanation, but I think minor modifications of the test-case can provoke all behaviours. I think 2 and 3 are of the same reason though (as described above) Thanks, I'll take a look. Ken By the way, I think the implementation of sendto/recv for datagrams is very inefficient when there are repeated calls to sendto as in your test case. Nevertheless, your test case actually runs slightly faster on the topic/af_unix branch than it does on master (when the latter succeeds, which it does about half the time for me). So I'm not sure whether it's worth worrying about this. Of course we would like the best throughput possible 😉 Here's the issue, briefly. The communication is done via a Windows named pipe. The receiver creates the pipe when it creates and binds its socket. It creates only one pipe instance. The sender connects to the pipe, writes, and closes its handle. But the pipe is not available for another sender to connect to until the receiver reads the message, after which it disconnects the sender. Ok, in our application we will use long lived descriptors and multiple writers that possible send large business messages (chunked into some smaller pieces per sendto()/recv()) Ken[Kristian] Best regards, Kristian -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Questions on how to upgrade Apache
Hi Cygwin, I got a question for you all. Our cyber security team is yelling at us to update Apache from 2.4.39 to 2.4.46. I have searched far and wide on the web to see if there is a way to do that, but so far nothing has turned up. Any idea on how to do this or if an updated package will get released soon-ish for Apache? Thank you in advance, -Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Questions on how to upgrade Apache
Got bounced at first, trying just this email… Hi Cygwin, I got a question for you all. Our cyber security team is yelling at us to update Apache from 2.4.39 to 2.4.46. I have searched far and wide on the web to see if there is a way to do that, but so far nothing has turned up. Any idea on how to do this or if an updated package will get released soon-ish for Apache? Thank you in advance, -Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: 3270
On Tue, Apr 06, 2021 at 12:44:28PM +0200, Cygwin List wrote: > On Tue, Mar 23, 2021 at 4:51 AM Peter A. wrote: > > On Sun, Mar 21, 2021 at 06:51:05PM +0100, Cygwin List wrote: > > > Hi, > > > > > > Do we have any c/s/x3270 maintainer? > > > Do we have any c/s/x3270 users except me? > > > > That would be me. I haven't had much time to try and package a new > > x3270. Also, the source package has changed form in such a way that I > > need to change how it's built entirely. > > So, if you have some problems with the current version let me know and > > I'll try and help. It could just need to be built against latest > > Cygwin. > > I need a new feature in version 4.1alpha7 (Double-clicking on a URL in > x3270 (on most platforms) and in wc3270 now opens that link in the > browser). I'll see what I can do. As I said, Paul reorg'd the source and it'll take some time for me to fix the build scripts. > Currently I am running wc3270 (native windows) because with that one I > can configure Right-Ctrl to be ENTER, and as I understand I can't do > that in c3270 (cygwin). Correct, c3270 can't be configured that way, but x3270 can (if you are willing to run the X server, that is). > Maybe I should just stick with wc3270. For the given requirement of Right-Ctrl, wc3270 is probably the easier option. > > > /Morten > > > -- > > > Problem reports: https://cygwin.com/problems.html > > > FAQ: https://cygwin.com/faq/ > > > Documentation:https://cygwin.com/docs.html > > > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- --=> Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com "Cats are just autistic Dogs" -- Dr. Tony Attwood -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
X11 blinking cursor in text window like 'gvim' - only halts if moved-over another X11-win
I don't recall this always being this way as I keep running into a problem with my input going into the wrong window. I've noted I seem to be relying on which editor(i.e. gvim) window in X11 has focus by noting that it has a blinking square cursor in the window at the cursor's current position in the edited text. If I move the windows cursor to another editor window in X11, the blinking cursor moves to the new window, but if I move it to a native window, the blinking doesn't stop. Has this always been this way? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
