tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


On Wed, 13 May 2015, Emmanuel Dreyfus wrote:

On Wed, May 13, 2015 at 02:02:26PM +0200, Joerg Sonnenberger wrote:
- fix _POSIX_THREAD_KEYS_MAX to be 128 instad of 256
This doesn't make sense. It should reflect the actual limit.

is the constant defined in the standard.

- increase PTHREAD_KEYS_MAX to 2048 so that we lead again for some time
  this would increase memory footprint of programs linked with -lpthread
  of 14 kB on ILP32 systems, and 28 kB on LP64 systems.

I am against raising it that much. The overhead is *per thread*, so it
sums up easily.

This is not my understanding of both the code and the documentation.
pthread_key_create(3) saus:
    The pthread_key_create() function creates a thread-specific data key
    visible to all threads in the process.

The data attached to a pthread_key_t is thread-specific. The array is

A queue doesn't make sense, O(1) is really required here. On-demand
growing of the array shouldn't be too hard to implement though.

I am not sure if we can use realloc() there. Even if we can, it means
we have to call malloc() on first usage.

I would guess that you wouldn't have to reallocate very often. Could you maybe do something like what the SYSV* code does? Allocate one big chunk of memory, and if you have to grow it, you allocate a bigger chunk, migrate all the old stuff to the new chunk (one entry at a time), and then free the old chunk?

Yup, it's not elegant, but it would not be a frequent occurrence. You simply need to use an "appropriate" increment.

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at  |

Home | Main Index | Thread Index | Old Index