Swiftloke 21:33:47
Can I kill a thread by getting its handle and doing svcCloseHandle?
profi200 21:37:40
Try it? I'm not sure what the effect will be (it's not the intended way at all). A duplicate handle will just be closed of course.
Swiftloke 21:40:48
How am I supposed to forcefully shut down a thread, then?
That way returns 0, but has no effect. Huh
@yellows8 21:42:04
you can't
Swiftloke 21:42:14
Yeah that's what I thought :(
Would make my code sooo much cleaner but oh well
profi200 21:46:23
The kernel is designed this way unfortunately.
calc84 21:48:03
Force-killing threads is almost always bad design anyway
Swiftloke 21:48:07
Why is that? I know killing threads is generally speaking a bad idea but there are valid use cases for it
(Such as killing worker threads)
Swiftloke 21:49:34
And while we're on the topic of threads...
calc84 21:49:39
But the thing is, you have to guarantee that the workers aren't working
Swiftloke 21:49:56
I've got this long standing bug in my app that started when I started talking to SRV
calc84 21:49:58
And at that rate, they might as well be waiting on an event while they're idle
Swiftloke 21:50:36
The moment I run srvEnableNotification some nasty stuff starts happening when the app closes
It seems that the libctru apt thread doesn't receive the shutdown signal, or at least, that's my theory
It'll end up at line 331, on svcWaitSynchronizationN
And it'll sit there for quite a long time, usually around 30 seconds
https://github.com/Swiftloke/ModMoon/blob/master/source/srv.cpp#L15
I've made sure it's not srvInit nor the worker thread
It's *only* when I run srvEnableNotification
(gdb) backtrace
#0  svcWaitSynchronizationN () at /home/davem/projects/devkitpro/pacman-packages/libctru/src/source/svc.s:271
#1  0x00129658 in aptEventHandler (arg=<optimized out>)
    at /home/davem/projects/devkitpro/pacman-packages/libctru/src/source/services/apt.c:331
#2  0x001256f4 in _thread_begin (arg=<optimized out>)
    at /home/davem/projects/devkitpro/pacman-packages/libctru/src/source/thread.c:37
#3  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
profi200 21:52:53
Verified in a minimum test case?
Swiftloke 21:53:18
This is the only thread that's still running, thread 1 is in svcSleepThread after _appExit
→ Sektor has joined
Swiftloke 21:53:31
You mean hooking up a tiny test app? Sure I can do that
profi200 21:53:40
Yes.
To rule out bugs in libctru.
Swiftloke 21:59:22
Can confirm it still happens. Shut down in about 18.5 seconds.
https://pastebin.com/yXmSRfc4
Anything stupid here?
Commenting out srvEnableNotification makes exit instant
@yellows8 22:01:34
waitsync on that handle?
Swiftloke 22:02:48
The way the real code works is by starting a separate thread to wait on that handle then run a callback based on that notification it is
That thread isn't the problem. It shuts down instantly.
profi200 22:03:14
Keep in mind you need to release resources.
Swiftloke 22:04:15
That occurred to me but I don't see a function to release the semaphore
@yellows8 22:04:36
close-handle
Swiftloke 22:05:01
WaitSynchronization doesn't help, I'll try that
profi200 22:07:15
That srvInit() is not needed btw. It's done internally already.
Swiftloke 22:12:58
Oh huh
Well sorry that took so long
But
CloseHandle doesn't help
profi200 22:17:09
And with srvInit() removed?
Swiftloke 22:19:25
Doesn't help
Is it safe to assume that this is a libctru bug, or is there something else to try?
profi200 22:21:57
Disable notifications before exiting? I'm not sure why this would cause that delay.
Swiftloke 22:22:36
There's no disable function in ctrulib
profi200 22:22:50
Hmm, ok.
← PaperDerp has left (Read error: Operation timed out)
Swiftloke 22:24:00
Or at all, just checked 3dbrew
profi200 22:24:04
So it's probably a bug. Try to test if it works correctly (ignoring the delay problem).
Swiftloke 22:24:37
Oh it works fine. In the main code I can receive events 0x208 and 0x20A (cartridge inserted/removed) without issue using that callback stuff
→ PaperDerp has joined
← PaperDerp has left (Client Quit)
profi200 22:25:51
Yeah, dunno what's causing the delay. It at least works.
Swiftloke 22:26:20
Problem is, this is kind of unacceptable to ship, one of my testers has said that it takes minutes to shut down
So, ugh
My theory is that this SRV thread gets the shutdown signal which causes APT to not receive it, somehow
Seeing as the thread that waits on that semaphore closes immediately
profi200 22:29:59
What if you pass it through to the main() loop and break out of it if you receive it?
Swiftloke 22:40:26
Removing the main loop then doing svcWaitSynchronization and immediately exiting when it occurs causes no change.
For that example I triggered an event by inserting a cartridge.
Event 0x208
→ PaperDerp has joined
profi200 22:42:11
Well, then i have no idea. Could be in libctru or could be a srv bug maybe.
Swiftloke 22:46:29
Ah, OK... Well, if anyone has any great ideas while I'm gone, please let me know. This has been bothering me since June and I haven't been able to find a good answer for it.
Swiftloke 22:47:31
Here's what I've got now
https://pastebin.com/Cn9MVLFL