Set stack size explicitly if pthread_create fails

[andralex]

Took me a while! I am testing 32-bit Phobos on Ubuntu64 running on VMWare hosted under OSX. Only in the 32-bit build, pthread_create would fail with the EAGAIN error code. It turns out, if thread stack size is explicitly set then it works.

[PetarKirov]

LGTM.
Tip to reviewers: the main change is in the first commit, the second is just whitespace, which is easier to review in Github with ?w=1 at the end of the URL.

[MartinNowak]

Looks like a hack for a resource problem.
http://stackoverflow.com/questions/8634736/pthread-create-and-eagain
Can you please try to find out what limit you're reaching? Out of memory because of stack creation sounds unlikely. How much RAM does your VM have?
http://man7.org/linux/man-pages/man3/pthread_create.3.html#ERRORS

[MartinNowak]

You can already explicitly set the stack size when creating a Thread object. Silently changing that to 16KB is a bad idea and might easily cause a stack overflow later on.

[andralex]

@MartinNowak I looked more into it and it's the stack size that's too big. Trying smaller sizes (yet greater than PTHREAD_STACK_MIN) sometimes works.

One possibility is to try a divide by 2 decay, i.e. if 8 MB (the default) doesn't work, try 4MB, then 2MB, etc. I'll do that in the next iteration of this diff.

[andralex]

@MartinNowak My VM has 4GB of RAM. Things fail even if I set it to 6 GB.

[andralex]

alright here we go

[schveiguy]

As much as I admire this binary decay (clever), it doesn't make sense that this would work. I would expect at most you could make one more thread (when resources are tight, and they really shouldn't be with 4GB of RAM). And you will get possibly random out of stack errors depending on which thread got the short end of the RAM stick.

I still feel like something strange is going on with your setup.

[andralex]

@schveiguy I hear you, but there's no action item. The simple thing is, I have a problem and this fixes it. My VM setup is as vanilla as they come.

FWIW 8MB is a large stack, most threads only use a few kb. It's a bit of a bummer that that's the default on 32 bits etc. etc.

[andralex]

I would expect at most you could make one more thread (when resources are tight, and they really shouldn't be with 4GB of RAM).

I suspect you're running into artificial limits, not actually exhausting resources.

And you will get possibly random out of stack errors depending on which thread got the short end of the RAM stick.

Those will segfault.

[Geod24]

I'm not confortable with this change either.

For starters, I doubt any user of a system programming language will expect the runtime to give it a stack smaller than what was asked for. If the stack size is the default one, that behavior might be okay, but it can also create hard to reproduce bug and I'm not sure that's where your actual issue lies.

FWIW 8MB is a large stack, most threads only use a few kb. It's a bit of a bummer that that's the default on 32 bits etc. etc.

You'll run out of virtual memory at around 3+ GBs, so that's < 0.3% of the virtual memory. Whenever that's disproportionate or not, having a default that's different from pthread's default is also confusing.

@MartinNowak My VM has 4GB of RAM. Things fail even if I set it to 6 GB.

It won't make any difference, since the memory isn't adressable by the process anyway.

[andralex]

I'm not confortable with this change either.

@Geod24 I don't get the action item. This is a solution to a problem in a context. What alternative do you propose?

For starters, I doubt any user of a system programming language will expect the runtime to give it a stack smaller than what was asked for.

This only kicks in if no specific stack size was asked for.

[schveiguy]

This only kicks in if no specific stack size was asked for.

That's not how it's written. If m_sz is 0, it reads the default, but it will still start halving even if it wasn't 0 to begin with.

In any case, my worry here is that on run 1, thread A gets a small stack size as compared to other threads, runs fine. On run 2, thread B gets a small stack size, but needs more.

Of course, one could say the alternative is that one thread doesn't run at all, which is a hard error. But at least you (should) see that happening, and it won't reach production.

Can we make this opt-in? So for instance, if you set the stack size to size_t.max, it uses the default, and then does the binary decay?

[MartinNowak]

How many threads are you creating? Is it RLIMIT_NPROC you're actually hitting?

[MartinNowak]

I am testing 32-bit Phobos on Ubuntu64 running on VMWare hosted under OSX.

Ah, it's the phobos tests. Why would you run out of resources for thread creation during phobos tests?
Which test does fail? What version of Ubuntu and VMWare are you using?

[andralex]

@MartinNowak The unittest is creating 100 threads, see https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/building_blocks/free_list.d#L1018. With a default stack size of 8MB per thread, we're looking at 800MB, which is quite a strain in a 32-bit app. I'll reduce that number to 20 and close this.