You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Under the current version (0.5.2), users could run a same pipeline with same parameters multiple times. This would raise a potential problem, i.e. I/O conflicts of same tmp folders. Further, users wouldn't realise this problem, as the error wound only appear in stdout and never appears in our main window.
The text was updated successfully, but these errors were encountered:
I agree that this is a concern. @colehurwitz is also thinking about this.
It seems to me that on a per element basis there are three possibilities:
Fully Concurrent: The element fully supports multi-instance concurrent execution. A bandpass filtering preprocessor, for example, should be able to run in multiple concurrent pipelines without any risk of failure.
Parameter Concurrent: The element supports multi-instance concurrency, but requires a per-instance change to its parameters. A sorter, for example, that has a save path may be able to operate concurrently with another instance of the same sorter if and only if the save path is set per instance.
Not Concurrent: The element has no support for multi-instance concurrency.
I'm tempted to solve this by adding a method to SpikeElement that would allow the app to query an element instance to determine its concurrency requirements, but I'm open to other suggestions.
Under the current version (0.5.2), users could run a same pipeline with same parameters multiple times. This would raise a potential problem, i.e. I/O conflicts of same tmp folders. Further, users wouldn't realise this problem, as the error wound only appear in stdout and never appears in our main window.
The text was updated successfully, but these errors were encountered: