IRC, freenode, #hurd, 2011-10-21:

<pinotree> maybe i'm missing something... what's the reason for not
  allowing setting a different stack size in libpthread?

2011-10-23:

<youpi> pinotree: the threadvars implementations
<youpi> which needs to find the variables according to sp value
<youpi> of course, since we now have TLS, threadvards can go away
<youpi> it's simply on the so-long TODO list

tls-threadvar.

2012-12-28:

Hurd commit 3a3fcc811e6b50b21124a5c5a128652e788a3b67 libports: remove the threadvars stack size hack.

IRC, freenode, #hurd, 2014-01-09:

<teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks
  proc
<teythoon> w/ the current debian libc that is
<teythoon> braunr: i reverted that patch and now it boots again
<gnu_srs> is alternate stack and arbitrary stack sizes supported by now, or
  upcoming?
<braunr> gnu_srs: supported
<braunr> well
<braunr> considering what teythoon just said, maybe not
<gg0> need to remove __pthread_stack_default_size from
  libpthread_hurd_cond_wait patch too i guess
<braunr> teythoon: i don't understand why this change has any negative
  effect :/
<braunr> or
<braunr> hm no ..
<braunr> there may be a bug in the latest glibc, where changing the stack
  is allowed on the ground that threadvars have been replaced with tls, but
  the libpthread stack handling code does it wrong
<braunr> see 714413a7694ff534855e9e5904899695eac6c9bb in libpthread
<braunr> which the thread destruction patches already did before it was
  fixed in libpthread
<braunr> and may explain why my packages work

IRC, freenode, #hurd, 2014-01-14:

<youpi> teythoon: Mmm, I tried to update to the latest hurd commits, but
  init dies early at boot
<youpi> exec init proc auth, and then init crashes
<youpi> downgrading libports to previous makes the issue go away
<braunr> youpi: previous ?
<youpi> previous debian package
<braunr> which patch makes it fail ?
<youpi> I'm bisecting
<braunr> i remember teythoon saying he had failures with the patch that
  removes the threadvars stack size hack
<youpi> I'll try that already, ok
<youpi> yes, boots fine without this change
<braunr> ok
<youpi> perhaps some missing patches in the current 2.17-97 glibc
<braunr> or libpthread reacting badly to new stack sizes
<braunr> is 714413a7694ff534855e9e5904899695eac6c9bb included in your glibc
  ?
<braunr> (714413a7694ff534855e9e5904899695eac6c9bb from libpthread)
<braunr> or maybe that's not the problem
<braunr> anyway, it's normally fixed with the thread destruction patch
<braunr> i did test it and checked the stack size were correct
<braunr> sizes*
<youpi> yes, debian's glibc has it
<youpi> ok
<youpi> so that can wait
<braunr> is 959f7365fccd1c89be9938c2655eba9122171e6a (Drop threadvars
  entirely) also in your glibc ?
<youpi> yes
<braunr> that's weird :/
<braunr> the only thing i can think of is __pthread_stack_alloc miserably
  failing with 2M stacks and "many" threads for some odd reason ..
<braunr> anyway, see you tomorrow
<gg0> hurd-i386/libpthread_hurd_cond_wait.diff keeps using
  __pthread_stack_default_size. isn't it the problem?
* youpi wonders what that change is doing there
<youpi> and it's there from the start of that patch...
<braunr> +  if (&__pthread_stack_default_size != NULL)
<braunr> checks if the symbol is actually resolved
<braunr> that's what allows regular applications to work
<braunr> it should be the same for hurd servers

sigaltstack

Likewise, sigaltstack is not usable at the moment.

IRC, freenode, #hurd, 2014-02-25:

<gnu_srs> braunr: are the split/alternate stack etc problems solved by now
  so gccgo can work properly?
<braunr> i don't know
<braunr> i suspect it wouldn't require much work now that tls is well
  supported
<youpi> alternate stack is supposed to be working