Keypress listeners not removed on Windows

[mszydlowski91]

Since in previous versions you had problems closing the readline interface, as it hanged Node event loop, you have worked the issue around by:

if (!/^win/i.test(process.platform)) { this.rl.close(); }

Which means that every time a prompt is created, a keypress listener will still remain, causing excession of max listeners and leading to memory leaks. Do you plan on fixing this rather dirty workaround? It makes the package either unusable or requiring heavy additional logic on Windows terminals.

[shirshak55]

@mszydlowski91 i noticed signit is also not working when i do ctrl+c. Is it due to this? and is there any alternative fix to this problem lately its giving lot of issue :(

[mszydlowski91]

@mszydlowski91 i noticed signit is also not working when i do ctrl+c. Is it due to this? and is there any alternative to this package i need it only for choice but lately it seems to have so much problem :(

UI.close method is invoked upon prompt runner completion, so I think it might be the same issue, although I never tested your case. Does it happen only on Windows terminals? If it works fine e.g. on tty, then it's very likely it's the same root cause.

[shirshak55]

@mszydlowski91 it happens on gitbash which is window terminal only. On OSX it works fine.

[mszydlowski91]

Yep, because the regex I pasted above only checks for win, so on OSX it works fine. Which makes sense, since Linux and OSX are basically the same core, so if rl.close doesn't hang event loop on Linux, then it likely works on all Unix systems.

[mshima]

This workaround is for a node bug:
nodejs/node#21771
But can be reverted if causes more problems then fixes.

[mszydlowski91]

Well, it kind of makes things worse as it tricks people into thinking it works fine, and then only after more thorough testing it turns out it's a ticking bomb. Right now it just forces you to do another dirty workarounds

[shirshak55]

hmm old version didn't have this issue right?