STR #1537

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.1 ]

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 wavexx
15:19 Dec 12, 2006
held.patch
1k
 
 
#2 mike
12:08 Jan 28, 2007
str1537.patch
1k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#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.  
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.