Possible bug in start/stop routines about facil.io HOT 4 CLOSED

I have looked over the defer.c's defer_perform_in_fork, and for me it seems, that the main culprit is defer.c:382

pids_count++;

This makes the loop under 'finish:' to fall over the allocated memory, deleting this line fixes the valgrind error.

Hope this helps :)

from facil.io.

Thanks 🙏🏻 🎉👍🏻👏🏻👏🏻

I re-read that piece of code and I have no idea what that line was doing there... 😂 I guess it was a leftover from a previous implementation.

Thank you very much for spotting it. 👍🏻

from facil.io.

Thank you for your work :)

Out of curiosity, why do you use hand-written spinlocks, and not mutexes?

from facil.io.

You're welcome :-)

why do you use hand-written spinlocks, and not mutexes?

It's a combination of performance testing and my own foolishness.

When I started the project, some of my design choices were a bit foolish and resulted in higher lock contention. Some of the lock contention issues couldn't be avoided (i.e. the defer library's queue access).

The original locking used mutexes and I noticed that mutexes were slower than I would like them to be. Something about the rescheduling mechanism was taking a long time to wake the threads up. Conditional variables weren't any better...

I tested it against spin locks using stdatomic.h . The spinlocks were noticeably faster for the defer queue (where contention can't be avoided).

But stdatomic.h wasn't available on Linux 14.04 (I was deploying on Heroku) so I just ended up writing the thing myself.

from facil.io.