| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]
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 ]
|
| |
