-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Non-stay_open and Non-singleton Mode in Cloud Function Environments? #190
Comments
Process forking in “serverless” setups can be problematic, which in turn makes this library’s architecture problematic. If I was going to implement this, we would completely skip batch-cluster and use the already-set-up process factory (without stay_open, as you mentioned). I would expect that per-call latency could jump to 200ms-1.5s. I’m not familiar with a way to simulate a serverless system within GHA, so testing it and reproducing any issues that arise would be problematic. If there is indeed a way to move forward with testing, I’d be more positive towards this feature. |
I've updated the constructors for the You can access the path to I'm not going to add "official" support for cloudless, though, given how I don't know how to test it rigorously with GHA. |
Hi,
I'm using exiftool-vendored in a cloud function environment
(There's no need to worry about the underlying Perl dependencies, as many serverless primitives can be configured to prioritize their installation.)
and I'm facing some challenges with the current implementation. I'd like to question a feature or configuration option that allows for a simpler, stateless execution mode. Here's the context and rationale:
Cloud Function Environment Characteristics:
Current Concerns:
end()
call can be problematic in this environmentstay_open
and singleton modes effectivelyProposed Solution:
new ExifTool()
that enables a simple, process-per-invocation modeend()
calls or process/thread pool managementRationale:
Would it be possible to add an option to
new ExifTool()
that enables this kind of straightforward, use-and-discard process mode? This would greatly simplify usage in cloud function environments and potentially other scenarios where managing long-lived processes is challenging.If possible, could provide an initialization code sample?
Thx!
The text was updated successfully, but these errors were encountered: