From 23504e0f01dc1eae05b307e313ba70faaad84be8 Mon Sep 17 00:00:00 2001 From: Christopher Baines Date: Thu, 30 Jun 2022 18:47:10 +0100 Subject: Support processing hook events in parallel Forcing hooks to be sequential simplifies them, and the implementation, but it doesn't always scale well. I'm particularly thinking about the build-submitted hook and built-success hooks, the processing of which can back up if there's lots of builds being submitted or finishing successfully. This new functionality allows hooks to be processed in parallel, which should allow to manage this more effectively. --- guix-build-coordinator/datastore/sqlite.scm | 32 +++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'guix-build-coordinator/datastore/sqlite.scm') diff --git a/guix-build-coordinator/datastore/sqlite.scm b/guix-build-coordinator/datastore/sqlite.scm index bbd9c28..a6c93f3 100644 --- a/guix-build-coordinator/datastore/sqlite.scm +++ b/guix-build-coordinator/datastore/sqlite.scm @@ -80,6 +80,7 @@ datastore-insert-unprocessed-hook-event datastore-count-unprocessed-hook-events datastore-list-unprocessed-hook-events + datastore-find-unprocessed-hook-event datastore-delete-unprocessed-hook-event datastore-list-agent-builds datastore-agent-for-build @@ -2480,6 +2481,37 @@ LIMIT :limit" events))))) +(define-method (datastore-find-unprocessed-hook-event + (datastore ) + id) + (call-with-worker-thread + (slot-ref datastore 'worker-reader-thread-channel) + (lambda (db) + (let ((statement + (sqlite-prepare + db + " +SELECT event, arguments +FROM unprocessed_hook_events +WHERE id = :id" + #:cache? #t))) + + (sqlite-bind-arguments + statement + #:id id) + + (let ((result + (match (sqlite-step statement) + (#f #f) + (#(event arguments) + (list (string->symbol event) + (call-with-input-string arguments + (lambda (port) + (read port)))))))) + (sqlite-reset statement) + + result))))) + (define-method (datastore-delete-unprocessed-hook-event (datastore ) id) -- cgit v1.2.3