End doesn't always have control

[Dude]

I've got a massive app which creates a lot of threads and windows, which I can't post here.

One of my events from my main loops checks if "Quit" is selected in a menu, and if so, calls the "End" command. Sounds simple, right?

That's what I thought. But "End" doesn't seem to have the control that you'd expect. Despite calling it, sometimes the app keeps running in the background, with 50% CPU. It's like it's not auto-ending all threads and windows for some reason.

Here's basically what I'm doing:

Code: Select all

If quit=1
  Debug "gone"
  End
EndIf

But despite me seeing "gone" in the Debug Output window, my app is still running. WTH? Doesn't "End" mean end? Is there a way I can actually "End" my app at any moment?

[skywalk]

Presumably, you have an internal list of all your threads? Create a shutdown procedure that signals their closure or kill them after a timeout.

[Dude]

I could do that, but I really want to know why "End" just doesn't end like it's supposed to. "End" is supposed to kill all child threads for me, instead of hanging the app.

[Dude]

Turns out it's because the threads used windows that were created with #PB_Any. When I changed that to use enumerated hard-coded window numbers, the app does now end normally and cleanly when "End" is reached. Just putting this here for future reference.

[Crusiatus Black]

I think it would still be a better practise to clean up the threads yourself, as killing them is never clean. I usually have a thread context structure which each thread receives when started. This structure has flags, and if the kill flag is set (by me elsewhere in code), the code in the thread will detect it and stop executing (gracefully).

I had way too many issues with threads in the past upon exiting the program...

[Dude]

I think it would still be a better practise to clean up the threads yourself

100% agree, but shouldn't "End" just end? What's the point of having an "End" command if it won't?