[libcamera-devel] question about Requests

[paul.elder at ideasonboard.com]

Hi David,

On Fri, Oct 16, 2020 at 10:47:30AM +0100, David Plowman wrote:
> Hi everyone
> 
> I've been updating my libcamera apps to use the new Request functions
> (unique_ptrs and reuse), and I ended up re-inventing the same code as
> has been put into qcam (lists of unique_ptrs, "free" Requests, another
> mutex). I did find myself wondering whether this could be hidden in
> libcamera.
> 
> For example, createRequest() gives you a raw pointer, but which
> libcamera always owns. When a Request completes and you're done with
> it, call reuse() and the next call to createRequest() is allowed to
> give it back to you.

Ah, you're proposing that libcamera keep a Request pool. To be honest,
that does sound very enticing. The issue is though, that the Request
would have to be returned to libcamera at the end of the Request
completion handler in the application. The Request completion handler
can't be long, as it runs in the libcamera thread context. So, if the
application wants to do any long process with the Request, it would have
to make a copy of the Request (like qcam did before the reuse request
patch).

On the other hand, if the application keeps the Request pool, then the
Request would still be valid after the request completion handler
completes, simplifying any processing done on the Request afterward
(like qcam after the reuse request patch).

One option would be to explicitly return the Request to libcamera after
the application is done with it, maybe camera_->returnRequest(request) ?
As opposed to automatically returning it after the completion handler
completes. request->reuse() as you've proposed (and what's in use now)
only resets the state of the Request.

Another option is to have a helper pool class for applications to use.

> Possibly I don't understand the bigger picture here, it was just a thought!

Interesting thought :)


Thanks,

Paul