| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1537
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | awake() improvements |
|---|
| Version: | 1.1-current |
|---|
| Created By: | wavexx |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1-current (SVN: v5646) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | wavexx
15:19 Dec 12, 2006 |
| It's important for awake() to never lock. In the current implementation for pthreads, awake() will write to the pipe without checks, eventually filling the pipe buffers and wait. If the locks are still held, this will cause a deadlock. Attached patch allows awake() to be used in such conditions without changing the behavior. WIN32 does not have this problem. | |
| |
| #2 | matt
13:14 Jan 18, 2007 |
| I don't know enough about this issue. Can anyone help? | |
| |
| #3 | wavexx
10:58 Jan 27, 2007 |
| I noticed now the state of this report.
Maybe I can clarify more with a simple case:
On posix awake() expects to write to the pipe in order to notify the select() call. In order to be able to call awake() _before_ calling unlock() (which is THE correct way) FLTK assumes pipes are buffered. This is true, pipes are buffered, but the buffer is not unlimited. If you call awake() enough times to fill the buffers, awake() will eventually lock on write(), resulting in a deadlock.
awake() should never lock. | |
| |
| #4 | mike
11:51 Jan 28, 2007 |
| A better fix would be to simply make the pipes non-blocking... | |
| |
| #5 | mike
12:08 Jan 28, 2007 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
