That moment when instead of debugging, you use cout to see the results...

So I'm writing some multithreaded shit in C that is supposed to work cross-platform. MingW has Posix threads for Windows, so that saved already half of the platform dependency. The other half was that these threads need to run external programs.

Well, there's system(), right? Uhm yes, but it sucks. It's incredibly slow on Windows, and it looks like you can have only one system() call ongoing at the same time. Which kinda defeats the multithreaded driver. Ok, but there's CreateProcessA(), and that doesn't suck.

Fine, now for Linux. The fork/exec hack is quite ugly, but it works and is even fast. Just never use fork() without immediate exec(). First try under Cygwin... crap I fork bombed my system! What is this shit? Ah I fucked up the path names so that the external executable couldn't be run.

Lesson learnt: put an exit() right after the exec() in the path for child process. Should never be reached, but if it goes there, the exit() at least prevents a fork bomb.

Well yeah, sort of works under Cygwin, but only with up to 3 threads. Beyond that, it seems like fork() at some point gives two processes the same PID, and then shit hangs.

Even slapping a mutex around the fork and releasing it only in the parent process didn't help. Fork in Cygwin is like a fork in the ass. posix_spawn() should work better because it can be mapped more easily to the Windows model, but still no dice.

OK, testing under real Linux. Yeah, no issues with that one! But instead, I get some obscure "free(): invalid size" abort. What the fuck would that even mean?! Checking my free() calls: all fine.

Time to fire up GDB in the terminal! Put a catch on the abort signal, mh got just hex data. Shit I forgot to compile with -O0 and -g. Next try. Backtrace shows the full call trace, back to the originating line in my program - which is fclose() on a file.

Ahhh I remember! Under Linux, fclosing a file that is already closed makes the program crash. So probably I was closing it twice. Checking back.. yeah that's where it was.

Shit runs fast on several cores now!

@12bitfloat Serious debate on Rust vs C here are my arguments; C has :

1. Better Syntax
2. Betetr Performance (Compile and runtime)
3. Direct Hardware Access (No strict rules)
4. Lots of codebases use `unsafe` in rs
5. No Borrow Checker Frustrations
6. Established Ecosystem
7. More Control Over Memory
8. Easier to Port & Embed
9. No Heavy Standard Library
10. EASY Manual memory management (that's a pro)
11. Optimal inline assembly
12. Memory-mapped I/O (simpler pointer math)
13. No fat pointers ( slices)
14. Better control over ABI
15. Lighter executables
16. Simple linking (no cargo)
17. Cargo forces u to use GitHub
18. More compiler choices (GCC, Clang, TinyCC, MSVC, ICC, etc)
19. More debugging tools (GDB, Valgrind)
20. Cross-compilation is easier (and there's Zig support)
21. Easier to distribute AND RUN ON WINDOWS
22. Better for baremetal (Rust needs a custom runtime for truly bare-metal execution)
23. Compatible with legacy systems (Rust is too heavy to support some old architectures)
24. Better for microcontroller (no_std/std)
25. Supports every OS(sunOS, solaris, obscure BSDs)
26. No forced updates (cargo updates takes a year and installs I36579+E package)
27. Less strict versioning (new standard broke my old code)
28. Less restrictive aliasing
29. Flexible pointer types (ever heard of Box<T>)
30. No unwarranted type safety (Sometimes you just need a void*)
31. C99 flexible arrays
32. Anonymous structs/unions (less boilerplate than enums)
33. C macros are simpler (please help me rusts' require a mini language at this point)
34. No strict mutability rules
35. Better for hacking/debugging (poke around memory)
36. Better C++ interop (C++ sucks)
37. More lib-friendly (almosts every lib has C bindings)
38. Can use void pointers (void*)
39. Better for writing shared libraries (Rust’s dynamic linking is more complex)
40. No automatic drop semantics (Rust’s Drop trait can introduce performance issues)
41. No forced monomorphization that causes binary bloat
42. Better for real-time applications (No automatic memory management surprises)

MENTION : I'm not clashing or anything, not against the person I'd like to debate with, @12bitfloat, but against the argument (RUST>C)
It's not a war

Fucking gdb with your stupid commands, showing me the memory allocation, shos me the data you stupid piece of shit, what is the value pointed by the pointer.

*Segmentation fault**core dumped*

Oh gdb! How much I missed you. Please don't ever leave me okay?

Why does GDB always set the bloody break point one line above or below where I want it to be. This is driving me nuts. It's like its author deliberately planted a nasty practical joke in the code.