Is it possible to set the stack size of an ALLEGRO_THREAD?
I don't know what you mean. What is the stack size? You mean the heap vs stack stack?
You can't make an ALLEGRO_THREAD on the stack. It's an opaque data structure. You can only create and destroy them using al_create_thread and al_destroy_thread.
I assume Aldrik means - is it possible to set the amount of memory allocated to a new thread's stack when it's created? (each thread has its own stack for subroutine returns and local variables, obvs)
This is possible with the underlying thread libraries (see http://man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html and https://docs.microsoft.com/en-gb/windows/desktop/ProcThread/thread-stack-size for example) but AFAIK not exposed to the Allegro API.
Sounds like a reasonable addition, pull requests welcome
.
SiegeLord, while you're here, what do you think of https://www.allegro.cc/forums/thread/617697 ?
SiegeLord, while you're here, what do you think of https://www.allegro.cc/forums/thread/617697 ?
We should be using UNICODE for things. We already do for most things, but somehow not joysticks. https://github.com/liballeg/allegro5/issues/397 is an issue that applies to this, fwiw.
I forked the allegro5 repo and am working on adding this feature. however, when I try to test it in a test project al_init fails (I think because of different versions?). Can anyone help me with this? I tried defining ALLEGRO_UNSTABLE in the test project but this didn't change anything.
Aldrik,
When al_init fails, it's usually because the runtime is not the same version as the version used to compile with. So you may have old DLLs somewhere.
I have made a pull request regarding this issue. This is my first ever contribution to an open source project so feedback is appreciated.
https://github.com/liballeg/allegro5/pull/992
I hesitate to say this but that 'pattern' of having an extended creation function ( al_create_thread_with_stacksize ) to go alongside the standard one ( al_create_thread ) is not consistent with other Allegro functions.
But the alternative is to follow displays and bitmaps, and have al_set_new_thread_option - which is more cumbersome! (given that there aren't many options available for creating threads beyond stack size and priority)
Code itself looks OK on first glance.
[edit] Hopefully Siegelord can comment.
I was set to work on it, it was for FileSystem as I remember it but I couldn't wrap my had around Win32 API. I'm still learning it so I can contribute.
Luck my liver, cause I have to digest it!