Suggestion for locking before mComputeQueue->submit()

[troelsy]

I mentioned briefly in #452 that GStreamer has to lock and unlock a mutex before calling this->mComputeQueue->submit. I thought I would do a separate PR, so we had something concrete to discuss. This is a draft of how I imagine the interface could look like.

I have a feeling that others might need this as vkQueueSubmit is not thread safe. In our use case, we have lots of threads and GStreamer gives us the lock that all GStreamer elements share. In this PR, the locks are no-op functions if nothing is given to the kp::Manager constructor, but we could also create a mutex inside kp::Manager.

I have suggested that we create a struct to hold the locks, but they could also be separate arguments. I'm not checking if both are set or unset, but it could also be added to the constructor.

 struct LockCallbacks {
  std::function<void()> lock;
  std::function<void()> unlock;
};

This is how we initialize the locking struct

kp::LockCallbacks queue_lock_callbacks = {
    [gst_queue]() { gst_vulkan_queue_submit_lock(gst_queue); },
    [gst_queue]() { gst_vulkan_queue_submit_unlock(gst_queue); }
};

where gst_queue is a pointer to GstVulkanQueue

[axsaucedo]

Thanks! Just had a quick read - few qs:

Why do we need to add these as a std::function as part of the lock?

ie instaed of just implementing a lock

Also - is this something that needs to go as part of the Sequence? i.e. vs having this as a separately managed lock at the application layer