Bug #1102
closed
TouchProcessor fails on pinet to exit or notify on exit when running on pistore.
100%
Description
Failure on pinet shutdown on a pistore:
piboxTouchShutdownProcessor[touchProcessor.c:619] ERROR Timed out waiting on touchProcessor thread to shut down.
Doesn't happen all the time and the timeout eventually clears the problem.
Updated by Hammel about 1 year ago
- Severity changed from 03 - Medium to 01 - Critical
Updated by Hammel 12 months ago
- Status changed from New to In Progress
- % Done changed from 0 to 30
This might be due to the animation timer interfering with the SIGINT processing. There was no call to g_source_remove() in pinet.c on shutdown.
This is fixed in my sandbox but needs to be tested thoroughly on hardware.
Note that the following all need updates related to the SIGINT call.- picam
- musicfe
- pipics
This means they all need this code on shutdown.
if ( isCLIFlagSet(CLI_TOUCH) )
{
/* SIGINT is required to exit the touch processor thread. */
raise(SIGINT);
piboxTouchShutdownProcessor();
}
- pistore
- pinet
Updated by Hammel 11 months ago
- % Done changed from 30 to 50
All changes are implemented but all changes need to be tested on hardware.
Kiosk can be used to test the following:- pipics: passed
- picam - passed, after fixing location of touch handler shutdown.
- pinet - fail
- Musicfe: Passed
- pistore: passed
Updated by Hammel 4 months ago
- % Done changed from 50 to 80
pinet is still failing with this even though the code looks correct. It still times out waiting on the touch processor.
I'm not sure I really like this mechanism as it relies on a signal in stead of a more robust mechanism like a thread variable or semaphore.
In any case, all of the code can be committed and pushed. Then I just need to fix pinet from here.
Updated by Hammel 4 months ago
Possible issue: picam doesn't have ANY signal handling. Just add the same thing I put in pinet and see if that helps.
Update: looks like ONLY pinet has signal handling. pistore doesn't have it. musicfe doesn't have it. pipics doesn't have it. In fact mfe and pipics have it but it's been disabled (#if 0'd). Still, I want to try adding it to see what happens.
The problem here is that ts_read() in piboxlib:touchProcessor() is blocking and will only interrupt on SIGINT. We can make it non-blocking with a call to ts_setup but I don't know if the code is setup to handle non-blocking reads. I'll have to experiment. If we can use non-blocking calls then we can use a semaphore to shutdown the touchprocessor, which will be much cleaner than SIGINT.
Updated by Hammel 4 months ago
touchProcessor() calls ts_setup(xxx,0) which means blocking reads. If it would call it with ts_setup(xxx,1) then it would be non-blocking. touchProcessor() calls ts_read(xxx,1) meaning it just wants one entry so the code right after that, if (ret==0), handles a non-blocking return.
So technically, all that should be required is to have touchProcessor() call ts_setup(xxx,1) and it should just work. I MIGHT need to put a minor delay in the if(ret==0) block to keep touchProcessor() from hogging CPU time, however.
If I do this then the shutdownProcessor() call can just use a semaphore to break out of the touchProcessor() loop.
To test: make the mods to libpibox and push the .opk to the node to test. It either works or it doesn't.
Updated by Hammel 4 months ago
- Status changed from In Progress to Closed
- % Done changed from 80 to 100
Wow. Fixed this!
The fix wasn't to use a semaphore. There was already loop management integrated into touchProcessor(), I just wasn't using it correctly. When fixed and switched to non-blocking reads, the whole thing just works a ton better.
Tested with picam, pinet, and pistore. All of which now exit much faster and cleanly.
Code (piboxlib:touchProcessor.c was the only change) committed and pushed.
Closing issue.