Re:What happens before main() is executed in C and why is it...
by dicroce on Friday May 04, 2018 @01:36PM
(#16996464)
Personally, I think global's with constructors are kind of an anti pattern. I've noticed a high correlation between crappy app's and app's with a lot of pre main() code. Especially if some of your global's have threads: because then you potentially have threads running AFTER main exits... I've seen a number of apps with random crashes at shutdown because a thread that was started in a global was still running and since main returned globals were being cleaned up and the thread used something that had just been cleaned up.
[ Parent
| on HN ]
Re:What happens before main() is executed in C and why is it...
by pensono on Friday May 04, 2018 @01:52PM
(#16996639)
This article seems to be targeted toward embedded programming, so global state isnt that big of a deal because you have complete control of the chip. It's quite common to not even have threads or an operating system at all.
Re:What happens before main() is executed in C and why is it...
by drb91 on Friday May 04, 2018 @04:26PM
(#16997993)
This is a real problem; i’m not sure rooting all mutable state on the stack will help in this case without language-level metadata restricting frees, passing references, and dereferencing.
It seems like the rust answer of making it difficult to share mutable state is a solid answer—you explicitly manage concurrent state, rather than implicitly allowing sharing. In addition rust has some interesting run-once constraints you can add to closures that work well with global initialization. I’ll admit I haven’t seen enough rust to see it work well in action, but the pieces are there.