Opened 9 years ago
Last modified 8 years ago
#1325 new defect
qt-light egg: timers may put chicken into an inconsistent state
| Reported by: | John Foerch | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | someday |
| Component: | extensions | Version: | 4.11.0 |
| Keywords: | Cc: | ||
| Estimated difficulty: |
Description
I have found that a Qt::Timer may be used to make callbacks into chicken faster than the callbacks themselves can finish. This puts chicken into an inconsistent state and causes a crash. Here is a test case - callback rate and count may need to be adjusted for faster machines.
(import chicken scheme)
(use qt-light)
(qt:init)
(let* ((thread-rate 0.025)
(timer (qt:timer thread-rate)))
(define (timer-callback)
(let loop ((i 0))
(if (< i 1e6)
(loop (+ i 1))
#t)))
(qt:connect timer "timeout()" timer-callback)
(qt:start timer)
(qt:run))
$ ./minimal.scm Warning: excluded identifier doesn't exist in module foreign: foreign-declare Warning: excluded identifier doesn't exist in module foreign: foreign-declare csi: runtime.c:2797: C_save_and_reclaim: Assertion `av > C_temporary_stack_bottom || av < C_temporary_stack_limit' failed. Aborted
Since Qt must be used for the main event loop in a Qt program, making timers safe to use would be fairly important for the qt-light egg. Without knowing much about the internals, I think that maybe a semaphore could be used to block a callback if a previous callback has not finished. When this occurs, it would be nice if the api also exposed a way for a chicken program to know that a callback was dropped, so that it could take an appropriate action.

It sounds like these callbacks are executed in a different thread. This is explicitly not supported. You could set up something in pure C which writes to a mailbox or some such (perhaps with the concurrent-native-callbacks egg)
So I don't think this is a bug. Can you maybe provide some more information about how this works in QT?