Amazing! My joke functionality worked and the server delivered it's content successfully to the client. The joke: malloc is wrapped to give that message and retry IMMEDIATELY. Expectation is that the computer that was already in panic mode gets even fucked up more because it's out of memory. My malloc is literally while((ptr=malloc()} == NULL) { show_warning()
;malloc();}. Imagine if it didn't give that warning, I would've never known that a malloc failed. Who checks their freaking malloc result? You should, but i do not see much people doing it.

The previous crash on screen is what happens if you're doing a get instead of a post. I just declare my server app indestructible btw. Ffs!

It's a sqlite 3 rest server writing in one day. The json parser / serializer js written some other day but also by me. The http request parser also is written by me once. It only has sqlite3 as dependency

The malloc wrapper function. It swapts with real malloc.

Amazing btw, it just realize now that it's not thread safe and other projects that thread very heavy are using it a lot. It seems that incrementing a var without checking it beforehand only is no problem. Have to check if that's true. Hmm, how would thread locks else work? Smth like this with a volatile var?

@chatgpt how does a thread lock work in C, how is it made thread safe?

@retoor
In C, a thread lock (also known as a mutex) is typically implemented using the `pthread_mutex_t` data type from the POSIX threads library. Here's how a thread lock works in C:

1. **Initialization**: To use a thread lock, you first have to initialize it using `pthread_mutex_init` function which creates a new mutex. You should always initialize a mutex before using it.

2. **Locking**: When a thread wants to access a critical section of code or a shared resource, it must first lock the mutex using `pthread_mutex_lock`. This operation blocks the thread until the mutex is available for locking.

3. **Critical Section**: Once a thread has locked the mutex, it can safely access the critical section of code or shared resource that needs protection. This ensures that only one thread can access the resource at any given time.

4. **Unlocking**: After the thread finishes using the critical section, it must unlock the mutex using `pthread_mutex_unlock`. This releases the lock, allowing o

ther threads to acquire it and access the critical section themselves.

To make code thread-safe using a mutex, follow these guidelines:

1. **Protect Critical Sections**: Wrap the critical section of code that accesses shared resources with mutex lock and unlock operations to ensure only one thread accesses the resource at a time.

2. **Avoid Deadlocks**: Be careful not to create deadlocks by always following a consistent order when locking multiple mutexes. Deadlocks can occur when threads are waiting for each other to release a mutex indefinitely.

3. **Error Handling**: Always check the return values of mutex operations to handle errors gracefully. For example, you can check for errors returned from `pthread_mutex_init`, `pthread_mutex_lock`, and `pthread_mutex_unlock`.

By using mutexes to manage access to shared resources, you can create thread-safe code in C that prevents race conditions and ensures data integrity in a multi-threaded environment.