| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Is this an overkill? I don't know.
The thing is, correctly intercepting SIGTERM (also SIGINT, etc.) is
incredibly tricky. For example, before this commit, my I/O loops in
server.c and worker.c were inherently racy.
This was immediately obvious if you tried to run the tests. The tests
(especially the Valgrind flavour) would run a worker, wait until it
prints a "Waiting for a new command" line, and try to kill it using
SIGTERM. The problem is, the global_stop_flag check could have already
been executed by the worker, and it would hang forever in recv().
The solution seems to be to use signalfd and select()/poll(). I've never
used either before, but it seems to work well enough - at least the very
same tests pass and don't hang now.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Modifying cmd_dispatcher fields like that make it inherently unsafe to
call cmd_dispatcher_handle_conn concurrently.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Remember, this is always a mistake:
ptr = realloc(ptr, size);
You still need to free() the original ptr if realloc fails.
|
| |
|
|
|
| |
It now increases the buffer size exponentially until it finishes reading
the file.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Unless ulimit -n is set, I get errors such as this from valgrind:
Assertion 'newfd >= VG_(fd_hard_limit)' failed.
I don't know and don't care what this is about; settings ulimit -n to
something else seems to do the trick. For reference, this can be used:
https://www.mail-archive.com/kde-bugs-dist@kde.org/msg778326.html
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OK, this is a major rework.
* tcp_server: connection threads are not detached anymore, the caller has
to clean them up. This was done so that the server can clean up the
threads cleanly.
* run_queue: simple refactoring, run_queue_entry is called just run now.
* server: worker threads are now killed when a run is assigned to a
worker.
* worker: the connection to server is no longer persistent. A worker
sends "new-worker", waits for a task, closes the connection, and when
it's done, sends the "complete" message and waits for a new task.
This is supposed to improve resilience, since the worker-server
connections don't have to be maintained while the worker is doing a CI
run.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also, move some stuff to net.c where it belongs.
|
| | |
|
| | |
|
| |
|
|
|
| |
We only build using "Unix Makefiles" anyway, which is a
single-configuration build system.
|
| |
|
|
| |
Also, some minor refactoring.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
* I don't really need to declare all variables at the top of the
function anymore.
* Default-initialize variables more.
* Don't set the output parameter until the object is completely
constructed.
|
| | |
|
| |
|
|
|
|
| |
Everything was broken starting from the "making struct ci_queue_entry
opaque" commit. Damn, I really wish I'd have some kind of automated
testing to catch errors like this...
|
| | |
|
| | |
|
| |
|
|
| |
Turns out, I don't really need to install it for the tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This was quite a bit of refactoring in test/; everything should be
more maintainable and robust in theory.
Also, valgrind.sh was fixed to use exec (so that signals are passed to
the underlying process); Valgrind command line options have also been
tweaked.
./ci.sh fails now, but that should be fixable.
|
