Timeline for C++14 Async Task Scheduler
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 28, 2015 at 1:25 | comment | added | David |
Well, there's probably a reason it didn't get into the standard. While you need lock_guard to manage exceptions safely, there is no potential unsafety in not locking when you leave the scope from a thrown exception. Not that I'm particularly against it, but I'm not bringing in boost as a dependency for unlock_guard, and I'm not writing some boilerplate for it in this class either. I suppose it would save 1 line of code, heh.
|
|
| Jan 28, 2015 at 0:58 | comment | added | Loki Astari | The unlock_guard is a commonly requested feature. Alredy in boost. svn.boost.org/trac/boost/ticket/1850 I think it is worth wrapping anything that takes this pattern. | |
| Jan 28, 2015 at 0:35 | comment | added | David | Concerning the guarantee, if you add a task before the loop gets started it won't matter. Personally I don't think it's important to call out all the random things that work unconditionally. If it did depend on some random timing (whether the thread entered the loop or you pushed a task in first) it would just be broken, IMO. | |
| Jan 28, 2015 at 0:29 | comment | added | David |
Agreed about the lambda. I can change it to [&]{ run(); } and move the code to a private run function. Concerning RAII, it's all RAII-safe there (and there is no given construct to help anyway). lock is a unique_lock. Note I am unlocking and re-locking, not the other way around which is the lock_guard case.
|
|
| Jan 27, 2015 at 23:38 | history | answered | Loki Astari | CC BY-SA 3.0 |