Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thread ID exhaustion on 32-bit systems #3346

Closed
vicuna opened this issue Dec 8, 2004 · 3 comments
Closed

Thread ID exhaustion on 32-bit systems #3346

vicuna opened this issue Dec 8, 2004 · 3 comments
Milestone

Comments

@vicuna
Copy link

vicuna commented Dec 8, 2004

Original bug ID: 3346
Reporter: administrator
Status: closed (set by @xavierleroy on 2015-12-11T18:08:04Z)
Resolution: won't fix
Priority: normal
Severity: minor
Target version: 4.00.1+dev
Category: ~DO NOT USE (was: OCaml general)

Bug 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

@vicuna
Copy link
Author

vicuna commented Feb 2, 2005

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Feb 2, 2005

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Sep 11, 2012

Comment author: @damiendoligez

... 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.

@vicuna vicuna closed this as completed Dec 11, 2015
@vicuna vicuna added the wontfix label Mar 14, 2019
@vicuna vicuna added this to the 4.00.1 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant