| Anonymous | Login | Signup for a new account | 2013-05-25 16:59 CEST | ![]() |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |||||||
| 0003346 | OCaml | OCaml general | public | 2004-12-08 11:43 | 2012-09-11 09:38 | |||||||
| Reporter | administrator | |||||||||||
| Assigned To | ||||||||||||
| Priority | normal | Severity | minor | Reproducibility | always | |||||||
| Status | resolved | Resolution | won't fix | |||||||||
| Platform | OS | OS Version | ||||||||||
| Product Version | ||||||||||||
| Target Version | 4.00.1+dev | Fixed in Version | ||||||||||
| Summary | 0003346: Thread ID exhaustion on 32-bit systems | |||||||||||
| Description | Full_Name: Berke Durak Version: 3.08.2 OS: Debian Submission from: congruence.net1.nerim.net (213.41.151.68) Hello, In the context of a multi-threaded HTTP server, it seems quite plausible to wrap to negative thread ID's (at 1000 requests/second and one thread per request, this should happen in 12 days). I guess resetting next_ident to 0 after max_int should fix the problem. -- Berke Durak | |||||||||||
| Tags | No tags attached. | |||||||||||
| Attached Files | ||||||||||||
Notes |
|
|
(0003017) administrator (administrator) 2005-02-02 17:43 |
> In the context of a multi-threaded HTTP server, it seems quite plausible to > wrap to negative thread ID's (at 1000 requests/second and one thread per > request, this should happen in 12 days). Yes, this can certainly happen. But what problem do you envision with negative thread IDs? The only important property of thread IDs is that two active threads (not yet join-ed) have different IDs, and resources will be exhausted well before you have 2^31 threads simultaneously active. Best regards, - Xavier Leroy |
|
(0003019) administrator (administrator) 2005-02-02 19:28 |
> > In the context of a multi-threaded HTTP server, it seems quite plausible > > to > > > wrap to negative thread ID's (at 1000 requests/second and one thread per > > request, this should happen in 12 days). > > Yes, this can certainly happen. But what problem do you envision with > negative > > thread IDs? The only important property of thread IDs is that two active > threads (not yet join-ed) have different IDs, and resources will be > exhausted > well before you have 2^31 threads simultaneously active. ... and as thread ID's increase monotonically even if the number of active threads is bounded, they may wrap back and collide with the ID of an existing thread. Also, having negative thread ID's is not very nice in the logs. Now a sustained rate of 1000 hits/second is admittedly far-fetched for an amateur HTTP server ; however one may very well heavily use lots of threads in some other setting (think of a simulator) in which case the limit can easily be hit. Anyway this won't happen on 64-bit platforms. -- Berke Durak |
|
(0008055) doligez (manager) 2012-09-11 09:38 |
>... and as thread ID's increase monotonically even if the number >of active threads is bounded, they may wrap back and collide >with the ID of an existing thread. And wrapping from max_int to 0 would make that happen twice as fast. >Also, having negative thread ID's is not very nice in the logs. So print them as unsigned ints. >Anyway this won't happen on 64-bit platforms. We are now in 2012 and 32-bit is obsolete for any kind of high-performance work, so I'm closing this PR. |
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2005-11-18 10:14 | administrator | New Issue | |
| 2012-07-11 17:31 | doligez | Note Deleted: 0003018 | |
| 2012-07-11 17:31 | doligez | Target Version | => 4.01.0+dev |
| 2012-07-11 17:31 | doligez | Description Updated | View Revisions |
| 2012-07-31 13:37 | doligez | Target Version | 4.01.0+dev => 4.00.1+dev |
| 2012-09-11 09:38 | doligez | Note Added: 0008055 | |
| 2012-09-11 09:38 | doligez | Status | acknowledged => resolved |
| 2012-09-11 09:38 | doligez | Resolution | open => won't fix |
| Copyright © 2000 - 2011 MantisBT Group |