3 ms·

This comment was filled with fail. Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, includin

by phkamp 15y ago

This comment was filled with fail. Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, including your own. "Too dangerous" is a direct quote from a WG14 member. Stacksize is not an implementation detail, it often is crucial resource management issue for each individual application, in particular in high performance computing and network service applications. The C1X thread API provides no way you can set it. With respect to timed sleeps: You can simulate wall-clock sleeps with duration-sleeps, but not the other way around. Just that simple fact should make it clear why the API, if it can only offer one kind of timeout, should offer duration-sleeps. NTPD will step your clock up to +/- 3599 seconds. I happen to know: I helped write it.

forgotusername 15y ago
With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would be myopic). Following your argument, complex systems could not be designed without similar controls on memory allocator behaviour ("how can I allocate anything when I don't know if malloc() will introduce syscall latency for a size-32 allocation!?") or environment table size ("how can I possibly execute a subprocess if I can't be certain setenv() will always succeed!?"). The answer to both of course is that you don't design for the standard, you design (and measure) for a particular closed system. I can't see why stack size is any different from the two (of many) examples above. Re: absolute timeouts, the impossibility of emulating intervals reliably with wall-clock is a very good point.
- phkamp 15y ago
  First: Why should the API for setting stack-size be implementation defined, when a stack mandated to implement the language ? Second: You seem to labour under the misunderstanding that all threads in a program have, and should have the same stack size ? That's simply not true, you can look in Varnish for a good example: We may have 10 "overhead" threads with big stacks and 100.000 worker threads with small stacks. Third: You cannot add "some glibc function" to set the stack-size of a thread you have not yet created, and setting it afterwards may be impossible (if you want it larger) or cause memory fragmentation (if you want it smaller). Fourth: What does malloc(3) have to do with thread stacks ??
  - forgotusername 15y ago
    For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless. Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory, paging, and even where we're 10 years away from "complex system" interconnects powerful enough to provide shared memory across 10k+ computers filling a football field, how much longer would setting the stack size have any practical meaning. It would be like insisting on a frewindtapedrive() library call, because your machine happens to have a tape drive (and aren't files stored on tapes eventually!). Thankfully you weren't on the committee in the 1980s. ;) Nowhere did I suggest all threads should have the same stack size - if anything by the Go example, I suggested they might have no specific 'size' at all. malloc(3) has nothing to do with thread stacks, it was just an example of yet something else that has very implementation-defined behaviour, for which any standardized tuning API would probably come up short.
    - phkamp 15y ago
      Please give an example of an implementation of this thread API where having the ability to specify the desired stacksize would "be meaningless" ? Even on 64bit machines you can and will have memory fragmentation when you approach a million threads. PS: A bad analogy is like a wet screwdriver.
      - forgotusername 15y ago
        1) http://gcc.gnu.org/wiki/SplitStacks http://gcc.gnu.org/wiki/SplitStacks > This is currently implemented for 32-bit and 64-bit x86 targets running GNU/Linux in gcc 4.6.0 and later. For full functionality you must be using the gold linker, which you can get by building binutils 2.21 or later with --enable-gold. 2) You're still conflating heap and stack.
        phkamp 15y ago

by phkamp 15y ago

forgotusername 15y ago

With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would be myopic). Following your argument, complex systems could not be designed without similar controls on memory allocator behaviour ("how can I allocate anything when I don't know if malloc() will introduce syscall latency for a size-32 allocation!?") or environment table size ("how can I possibly execute a subprocess if I can't be certain setenv() will always succeed!?"). The answer to both of course is that you don't design for the standard, you design (and measure) for a particular closed system. I can't see why stack size is any different from the two (of many) examples above. Re: absolute timeouts, the impossibility of emulating intervals reliably with wall-clock is a very good point.

phkamp 15y ago
First: Why should the API for setting stack-size be implementation defined, when a stack mandated to implement the language ? Second: You seem to labour under the misunderstanding that all threads in a program have, and should have the same stack size ? That's simply not true, you can look in Varnish for a good example: We may have 10 "overhead" threads with big stacks and 100.000 worker threads with small stacks. Third: You cannot add "some glibc function" to set the stack-size of a thread you have not yet created, and setting it afterwards may be impossible (if you want it larger) or cause memory fragmentation (if you want it smaller). Fourth: What does malloc(3) have to do with thread stacks ??
- forgotusername 15y ago
  For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless. Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory, paging, and even where we're 10 years away from "complex system" interconnects powerful enough to provide shared memory across 10k+ computers filling a football field, how much longer would setting the stack size have any practical meaning. It would be like insisting on a frewindtapedrive() library call, because your machine happens to have a tape drive (and aren't files stored on tapes eventually!). Thankfully you weren't on the committee in the 1980s. ;) Nowhere did I suggest all threads should have the same stack size - if anything by the Go example, I suggested they might have no specific 'size' at all. malloc(3) has nothing to do with thread stacks, it was just an example of yet something else that has very implementation-defined behaviour, for which any standardized tuning API would probably come up short.
  - phkamp 15y ago
    Please give an example of an implementation of this thread API where having the ability to specify the desired stacksize would "be meaningless" ? Even on 64bit machines you can and will have memory fragmentation when you approach a million threads. PS: A bad analogy is like a wet screwdriver.
    - forgotusername 15y ago
      1) http://gcc.gnu.org/wiki/SplitStacks http://gcc.gnu.org/wiki/SplitStacks > This is currently implemented for 32-bit and 64-bit x86 targets running GNU/Linux in gcc 4.6.0 and later. For full functionality you must be using the gold linker, which you can get by building binutils 2.21 or later with --enable-gold. 2) You're still conflating heap and stack.
      - phkamp 15y ago