Skip to content

Conversation

@deavmi
Copy link
Owner

@deavmi deavmi commented Oct 1, 2023

Purpose

No longer want to use libsnooze. A condition variable with a mutex is safer with futex etc. Libsnooze had an FD and yeah, stuff could go wrong if a use closed those.

Todo ✍️

  • Future
    • What to do on SyncError?
    • Migrate
    • Fix issue
      • One issue is that a task completes too quickly, before anyone calls condvar.wait() and it therefore never wakes up. We must investigate this, perhaps we should wait(Duration) (with a low one, if it is set then exit, else the full blocking wait)
      • ☝️ Above will not work, between the time of full wait and after timedout wait and past another State check it could be set.
      • Solution: While loop with timeout
      • Better solution: Signal queue, meaning on addition wake up but also prior to wait we can immediately see a result there
    • Slumber interval
      • Configurable
      • Sane default
  • Sequential
    • What to do on SyncError?
    • Migrate
    • Slumber interval
      • Configurable
      • Sane default

deavmi added 2 commits October 1, 2023 15:21
- Removed `libsnooze` dependency
- Switched to `Condition` + `Mutex` technique
@deavmi deavmi self-assigned this Oct 1, 2023
@deavmi deavmi added the enhancement New feature or request label Oct 1, 2023
deavmi added 10 commits October 1, 2023 15:24
- Catch `SyncError` (but do nothing)
- Lock mutex, then wait on condition variable, when reawakening we have lock, then unlock it
- Switched to the `doWait()` mechanism with wakeups
- Added some debugging prints
- Stripped out `libsnooze` and now using condtiion variables with periodic wakeups
- Added missing import
- Waking interval is now configurable
- Print out any sync errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants