| Ticket UUID: | 2511420 | |||
| Title: | thread-20.15 hangs | |||
| Type: | Bug | Version: | None | |
| Submitter: | dgp | Created on: | 2009-01-15 21:24:03 | |
| Subsystem: | 80. Thread Package | Assigned To: | vasiljevic | |
| Priority: | 9 Immediate | Severity: | ||
| Status: | Closed | Last Modified: | 2009-05-04 07:21:05 | |
| Resolution: | Fixed | Closed By: | ferrieux | |
| Closed on: | 2009-05-04 00:21:05 | |||
| Description: |
Test thread-20.15 hangs because the command thread::rwmutex destroy $rwmutex blocks forever. | |||
| User Comments: |
ferrieux added on 2009-05-04 07:21:05:
Committed after review by mistachkin. ferrieux added on 2009-05-04 06:17:17: File Added - 325598: thr3.patch ferrieux added on 2009-05-04 06:07:03: Well, in fact it was a simple refcount leak in the error case. Patch included. ferrieux added on 2009-03-13 22:00:37: Given this, could we do a dichotomy with (1) The high level synchronization model (synchronous thread::send and eventloops) and (2) the trickier, low-level set of sync primitives (mutexes, r/w locks, condition vars) ? We could #ifdef out the script level exposition of (2), and bundle it ("Threads Lite" ?).
The idea is that (1) suffices for ~95% of uses of the Threads extension (otherwise the current bug would have been detected earlier), and as a consequence is much more "polished" than the lower half.
Just my $0.02...
dgp added on 2009-03-13 21:24:01: Any chance someone can look into these? I'd like to consider Thread for bundling with Tcl 8.6, but failures like this make me think it's not ready. | |||
Attachments:
- thr3.patch [download] added by ferrieux on 2009-05-04 06:17:17. [details]