Issue 47

[gnodet]

No description provided.

[ppalaga]

My main concern with the last commit is that we are adding the fourth (if I am counting correctly) thread on the client side. The threads are:

• main
• TerminalOutput.displayLoop
• TerminalOutput.readInputLoop
• This new one

Also the TerminalOutput owns an event queue. I wonder whether we could have just one queue and one thread hosting both display and dead daemon detection?

[gnodet]

My main concern with the last commit is that we are adding the fourth (if I am counting correctly) thread on the client side. The threads are:

• main
• TerminalOutput.displayLoop
• TerminalOutput.readInputLoop
• This new one

Also the TerminalOutput owns an event queue. I wonder whether we could have just one queue and one thread hosting both display and dead daemon detection?

You're right. The problem is that the TerminalOutput is used in 2 scenarii: when using the client, and when using a parallel build without a daemon (using the mvns script). This makes things a bit complicated to rework in a clean way.

[ppalaga]

@gnodet would you mind creating a separate PR for the last commit, so that we unblock the first three commits?

[famod]

FWIW, if you guys could provide me with a native image for Windows that incorporates 00aed21 (loopback address), I could test it before it is being released.

[ppalaga]

FWIW, if you guys could provide me with a native image for Windows that incorporates 00aed21 (loopback address), I could test it before it is being released.

That's highly welcome, thanks! A windows package will be available through the CI UI once @gnodet removes the last commit and the build will (hopefully) pass.

[famod]

@ppalaga Thanks for the pointer to CI. I forked this repo and activated GH actions so that I don't have to setup GraalVM and native stuff locally. It might be worth adding this as an alternative way to README.

[famod]

I think we should continue over there: #124

[ppalaga]

activated GH actions so that I don't have to setup GraalVM and native stuff locally.

What a trick! BTW, that's actually my strategy for Windows.

It might be worth adding this as an alternative way to README.

+1 a PR would be welcome.

[ppalaga]

The last iteration looks correct, but I'd like to think more about the performance impact and whether it can be done more effectively.

[ppalaga]

Merging as the perf impact does not seem to be perceivable, at least on my machine. I find the architectural concern still valid and I will file a follow up issue for that.