Still does not work all the time, there is probably a race condition somewhere

@bagong, You may want to give it a try and let me know how it goes for you.

I will have time in about 2 hours! Thanks a lot, so far!

With a detach to the resync thread, it exits with code 0. And I do not see any leaks, not sure about the original comment for MAC.

When you try it, let me know if you spot something weird.

Man, this looks great! When quitting sclang via the ide-menu, we still get the "interpreter forcefully crashed"-message, but if I shut it down with 0.exit, it closes with exit code 0!! And: scsynth is shut down, no zombie!!! I haven't tried it extensively yet, so hopefully no premature jubilation, but for now hurray!

• I also checked the other builds, the Linux and Apple breaks in terminalclient happen for me too, so I guess this will have to be for Windows only.
• If Apple and Linux crash, the likelyhood rises that the MinGW build breaks, but nooo, MinGW builds, that is great!
• I see diagnostic messages, I assume you want me to do something with them, please let me know.

I wrote this hectically, have to run... But I'll be back on this tomorrow! Thank you so much...

PS: Ah, one more thing, I saw you bumped up the Windows min-version to Win 7? I thought a bit about it, and I think it's okay, who uses Vista, I think even the ones depending on hacked versions will have updated by now ;) But would you mind putting that change into a dedicated commit, would be nice to see it in the commit history. As I said portaudio resets the min Windows version at some point, will have to look if that somehow interferes...

Best
.r.

Probably it's something stupid again, what I'm saying, but just in case. Maybe @crucialfelix 's explanation in this thread is relevant?

#2018

Two things here come to my mind now:

• as this seems to work, it would probably be possible to remove the workaround, Windows specific kill() in sc_process.cpp line 199?
• there is a cross-platform component in this problem too, as @vivid-synth's issue reminds me: .schelp errors break install with -DSC_DOC_RENDER #2024

But maybe we should ignore that? It's been around for a long time, did lead to several slightly different issue reports. Or do you (or somebody else, if others are following) have an idea if and how this could/should be fixed in an integrated way?

I can setup a build environment in Linux and have a look.

Regarding the kill, I would leave as a fail-safe. It should only activate
if the process didn't finish normally.

I can setup a build environment in Linux and have a look.

Oh wow, it would be great if you were willing to do that!

Regarding the kill, I would leave as a fail-safe. It should only activate
if the process didn't finish normally.

If it's possible to determine reliably if the process finished normally it might be useful in a pragmatic way. But it covers away the real problem and might allow the server zombies to remain? These are a constant source of user confusion, generating a lot of discontent (people get server boot errors and can't figure out that it's because of a server zombie). If you think the kill is better to have, maybe there is a safe way to kill the server alongside with sclang?

So you want to keep the kill? Sorry for being a nuisance...

I was removing it, while you were writing the message... :). I wanted to have separate commits, that's all.

Ah, okay, sorry, I misread your "done" ;)

Yep, I was in the middle of bathing the kids so had a hard "interrupt"

Damn, just removing the 'kill' let's both sclang and scsynth stay behind when the IDE is closed. Something specific for Windows seems to be needed, terminate() seems to have no effect whatsoever. No interpreter restart, classes-reboot, just nothing happens... You knew it, right? ;)

After reading the documentation with more attention, I think it is probably needed to do the terminateunder Windows too.

Yes, if I do the terminateunder Windows it works, so I have just committed that. Can you give it a try when you have some time?

Oh, the wait time was to short. Cool! Trying now!

Doesn't work for me :(
I get a status message: "error when passing data to interpreter" when I try to quit the interpreter.

So if I look for that error-status-message, it's in sc_process line 238:

    QByteArray bytesToWrite = commandString.toUtf8();
    size_t writtenBytes = write(bytesToWrite);
    if (writtenBytes != bytesToWrite.size()) {
        emit statusMessage(tr("Error when passing data to interpreter!"));
        return;
    }

Why does that test with .toUtf8? Everything unicode on Windows makes me nervous ;)

But obviously there is an error happening...

Perhaps the kill is necessary after all...

Which would mean, the most unpleasant side effect of the kill, the remaining zombies wouldn't actually be fixed. I've been doing this in Release mode builds. I can't see what is actually going on...

I can only see the status messages: the first time I try to stop the interpreter, I get "Interpreter failed to stop", after that in subsequent tries the "Error when passing data to interpreter". So something happened by terminate(), but not what is needed. Damn I can't even find the code that was there before kill() was introduced.

No way to debug this? I am having release builds here. Maybe something can be seen if stepping through this? Is it a boost thing? Maybe a special Windows terminate() in boost? (Blindly speculating ;) )

But how come it was working for you?

The 0.exit isn't executed when running it from the IDE menu...

But wasn't the 0.exit exiting ok on the 28th after the initial changes? It
wasn't leaving zombies. What's the difference, you think?

running 0.exit in the editor works as expected. stops the intepreter, and as it exits cleanly now, also stops the server.
But running the command "Quit interpreter" from the menu has no effect without the kill. And if closing the IDE, sclang and (if running) scsynth stay behind. This seems to indicate that the evaluateCode("0.exit", true); in that function stopLanguage doesn't work as it should on Windows?

OK, just to make sure I understand: 0.exit works without the kill, but menu
quit interpreter does not work without the kill (but works with the kill).
Is that right?

Yes:

evaluating 0.exit in the editor shuts down the interpreter properly

executing menu-item "quit interpreter" in the current state does nothing except display status message "interpreter failed to quit". "quit interpreter" must call that function stopLanguage too...

with the kill() the interpreter is closed (as before), but I assume (as before) - apart from being unclean - that scsynth won't be stopped on the kill of the interpreter as the interpreter has no opportunity to close properly.

Not sure if that means anything, but:if I step into that evaluateCode("0.exit", true);, the first message I get in the debugger is: <Error reading characters of string> while in qstring.h

It's midnight here... I have to go for now... cu then

I'll try to have another look at this

Thanks!

I have committed something that seems to work with the menu option to quit the interpreter.

BUT, I have been doing some more testing, and the 0.exit does not work all the time. I suspect a race condition when trying to cancel the read operation in sclang.

If you can try the menu option, that would be great.

Hi, @bagong, with this latest commit, it seems like the race condition is gone. I have been able to exit nicely both with 0.exit, and with the menu option, repeatably.

Very cool, building now!

I gave it the first shot, and it seems to be working perfectly now. Every time exit code 0

• evaluating 0.exit in the editor works as before
• quitting the interpreter from the menu with or without server running closes both cleanly
• closing SC with running interpreter (and running, even working server) also removes everything nicely

So that "race condition" only occurs if I stop from the IDE-menu? Is there anything/condition I should pay special attention to?

This seems fab!!! I'll have to look what you actually did now ;)

Let me know if you're happy with the current state yourself. I'll be playing around a bit with midi and plugins during the day, and if you don't want to add anything anymore we could send out test builds tomorrow? Agreed?

The race condition could trigger on both cases, but it seems like one was more likely...

Regarding the test builds, yes, I agree. The MIDI testing has been very limited until now, so it will be good to have some feedback.