| [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #1842
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Unassigned |
Summary: | fltk::Guard(RecursiveMutex *) works not as expected |
Version: | 2.0-current |
Created By: | anton146 |
Assigned To: | Unassigned |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
|
#1 | anton146 13:49 Dec 10, 2007 |
| I see two solutions:
make fltk::Mutex lock functions virtual
or don't derive RecursiveMutex from Mutex, because in current state it ISN'T a fltk::Mutex. if it's referred mixedly via Mutex * and RecursiveMutex * - there could be funny effects :) | |
|
#2 | anton146 14:36 Dec 12, 2007 |
| i think 'virtual' way's better, ATM I use this:
Index: fltk/Threads.h =================================================================== --- fltk/Threads.h (revision 5990) +++ fltk/Threads.h (working copy) @@ -34,9 +34,9 @@ Mutex(const pthread_mutexattr_t* a) {pthread_mutex_init(&mutex, a);} public: Mutex() {pthread_mutex_init(&mutex, 0);} - void lock() {pthread_mutex_lock(&mutex);} - void unlock() {pthread_mutex_unlock(&mutex);} - bool trylock() {return pthread_mutex_trylock(&mutex) == 0;} + virtual void lock() {pthread_mutex_lock(&mutex);} + virtual void unlock() {pthread_mutex_unlock(&mutex);} + virtual bool trylock() {return pthread_mutex_trylock(&mutex) == 0;} ~Mutex() {pthread_mutex_destroy(&mutex);} }; | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |