Demo hangs on Cygwin

[FredDeschenes]

Demo just seems to "hang" on the first step, even though the 'my_sleep' function executes and returns properly. It also does it in dry run mode (as shown in the screenshot), which suggests this most likely isn't an issue with the demo.

At first glance nothing unsupported by a basic Cygwin install seems to be used, which makes this even more puzzling.

I'll take a look tomorrow evening, but if anyone has any ideas in the meantime, feel free to share!

[themattrix]

Thanks for the issue submission! I'm just trying it on Cygwin for the first time myself.

It hung for me as well, but it didn't perform a dry-run. Are you sure you don't have CONCURRENT_DRY_RUN already set?

As for the hanging issue - it seems to be blocking on reading from (or writing to) the named pipe. Here's the last few commands before it hung:

+ printf '%s \e[1;37m%s\e[0m' 'Creating VM' '(on digitalocean)'
+ tput rc
+ read -r __crt__status
+ echo anim:
+ code=0
+ set -o errexit
+ trap INT
+ __crt__mark_task_with_code 0 0
+ local task=0
+ local code=0
+ echo task:0:0

Pressing CTRL+C runs the top-level signal handler, but then hangs at a familar place:

++ read -r __crt__status

My gut feel is that it's a buffering issue with the named pipe.

[FredDeschenes]

Yeah I worded that weirdly, I meant that it hung even in dry run mode (I tried both).

I just looked into this a bit before going to work and I found a couple of (old) Cygwin bugs relating to named pipes, including this one. I'll try to get more information on this tonight, but seems you were right about the named pipes!

[themattrix]

Ah, understood! I did some googling around last night as well, but wasn't able to find an obvious way to fix the issue. I'll likely look into this more in the coming days...unless you find something first!

[FredDeschenes]

So I've got some bad news...

I'm pretty sure I've found what the issue is. Digging around a bit, I figured out that we only got into the event loop once (the part with read -r __crt__status).

I've reproduced the issue in this simpler use case. brokenTest.sh will only output "foo", then get stuck there, but works as expected on Linux. workingTest.sh works fine on both Cygwin and Linux.

Basically, it seems you can only write to a FIFO once, which is not the case on Linux. This led me to this Cygwin bug in their mailing list, which seems to explain the same issue (although using C). The bug just celebrated it's third birthday, but the developer said "so if you can hang tight for a year or three, it may well get resolved", so it might get fixed soon :P

So yeah I guess this sadly isn't going to work on Cygwin anytime soon!

[themattrix]

I appreciate the research you've done into this! Seems like you are exactly correct. I wonder if there's another way to drive the event loop...

A little history: concurrent used to use wait -n (introduced in bash 4.3) for the first background process to exit. This got a bit more complicated when I introduced animations, and impossible when I introduced status updates for tasks. At that point I switched to using a named pipe which made everything much simpler. Going back to wait -n seems difficult.

Off the top of my head, another potential alternative is to have each writer append to a shared file, then have the event loop fed by a tail -f on that file. This would less efficiently emulate a named pipe, but may work on Cygwin.

I will look into this option (or others if you have any ideas) when I get some time.

[FredDeschenes]

Good idea with the tail -f, this seems to unlock the event loop properly (I can now see the animations and statuses being updated properly). Something else seems to be exploding later, I'll have a look at this too.

[FredDeschenes]

Mmm so the error I now have (still no idea what's happening, but something explodes when exiting, script exits with status 1)), but at least it also explodes on Linux! My bash-fu isn't so strong (I mainly use fish) so I probably broke something obvious. Anyway I'll look into it tomorrow/Sunday.

[themattrix]

Hello! I ended up implementing the event pipe as normal file on a branch here. It works great in Linux and OS X, and theoretically should solve the problem in Cygwin (but I haven't tried it yet).

I was actually merely attempting to get nested instances of concurrent working (thus the branch name), but it seems that these features converged. 😄

[FredDeschenes]

Alright I'll have a look tonight, thanks!

[FredDeschenes]

Yup, that works fine, thanks!

[themattrix]

That's great to hear! I still want to hammer on it a bit more, but I'll close out this issue when I merge it in. Thanks for all your help!

[themattrix]

Just out of curiosity, does the display update really slowly in Cygwin for you? I'm using Babun, so maybe that's the reason.

[FredDeschenes]

Seems as fast as on a native Linux box, but I've only tried it on powerful machines so that might skew the results a bit.

[themattrix]

Ah, that's good! I was running it on a pretty beefy box as well, so probably just some quirk of my configuration. :)