My little CI system (hopefully) http://git.tensin.name/cimple/atom?h=meson 2026-09-21T17:19:05Z 2026-09-21T17:19:05Z Egor Tensin egor@tensin.name 2026-09-21T17:19:05Z urn:sha1:588fd2262c2f65e237a5a4e4858e06b4b87aaae3 2026-06-12T15:20:08Z Egor Tensin egor@tensin.name 2026-06-12T15:20:08Z urn:sha1:1160cdb21e0b667269299853cb47a4aa88948dc3 2023-12-12T20:29:42Z Egor Tensin egor@tensin.name 2023-12-12T20:29:42Z urn:sha1:82c5f204346def706fdc7ee28a8e2570fb880369 2023-06-09T07:23:54Z Egor Tensin Egor.Tensin@gmail.com 2023-06-09T07:23:54Z urn:sha1:9afecc03260a938fa57389ce3adffa5052df8076 2023-05-15T13:32:17Z Egor Tensin Egor.Tensin@gmail.com 2023-05-15T13:31:33Z urn:sha1:7cd83e15139447156ca915ce2d9d19295c146d56 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. 2022-08-28T13:14:07Z Egor Tensin Egor.Tensin@gmail.com 2022-08-28T13:14:07Z urn:sha1:0ff63a9ceff4c8fcd679b52cb1c03d96675f52f0 Previously, I had a stupid system where I would create a thread after every accept(), and put worker descriptors in a queue. A special "scheduler" thread would then pick them out, and give out jobs to complete. The problem was, of course, I couldn't conveniently poll job status from workers. I thought about using poll(), but that turned out to be a horribly complicated API. How do I deal with partial reads, for example? I don't honestly know. Then it hit me that I could just use the threads that handle accept()ed connections as "worker threads", which would synchronously schedule jobs and wait for them to complete. This solves every problem and removes the need for a lot of inter-thread synchronization magic. It even works now, holy crap! You can launch and terminate workers at will, and they will pick up new jobs automatically. As a side not, msg_recv_and_handle turned out to be too limiting and complicated for me, so I got rid of that, and do normal msg_recv/msg_send calls. 2022-08-26T02:05:02Z Egor Tensin Egor.Tensin@gmail.com 2022-08-25T14:58:38Z urn:sha1:532b3ae9b5cd8609237e04db768cc1f750d8631d This adds a basic "worker" program. You can now do something like ./server & ./worker & ./client ci_run URL REV and the server should pass a message to worker, after which it should clone the repository at URL, checkout REV, and try to run the CI script. It's extremely unfinished: I need to sort out the graceful shutdown, how the server manages workers, etc.