Skip to content
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

Processors that pipe incoming data through create invalid state #4

Open
sleistikow opened this issue Oct 29, 2024 · 2 comments
Open
Labels
bug Something isn't working

Comments

@sleistikow
Copy link
Contributor

Processors that can be disabled and hence set their input data directly as non-owned output cause an invalid state.
For details, consider the following network: A->B->C (Processor A connected to B, B connected to C).

Processor A calculates data and sets it to its outport. Processor B is disabled and would like to forward the data from its inport to its outport to pass it to C. If this is done in any method which is called by the NetworkEvaluator such as process(), processor C will still point to invalid or already deleted data (depending on what data was set to processor A's outport).
To fix this, the inport of Processor C needs to be informed immediately when the input of processor B changes (i.e. by clearing the outport of processor B).
This can be implemented by deriving from PortObserver in each and every processor that can pipe through its data and implement dataWillChange such that the output gets cleared right away.
This is quite cumbersome, since a lot of these processors might exist, so consider a different solution.

@sleistikow sleistikow added the bug Something isn't working label Oct 29, 2024
@sleistikow
Copy link
Contributor Author

sleistikow commented Oct 29, 2024

Just an idea:
What if we force every Processor to clear it's output immediately after it's input changed? It has access to all Outports and clear() is a virtual function in the Port class.
Is there a processor, that will hold it's output data even if the input changed? If so, is this a rare case such that not clearing the output would be opt-in behavior?

@ftilde
Copy link
Contributor

ftilde commented Oct 29, 2024

If so, is this a rare case such that not clearing the output would be opt-in behavior?

Both RandomWalker and OctreeWalker hold on to their output until a new result is computed.

In general, I think most (?) or at least a lot of AsyncComputeProcessors do so because they overwrite the output in processOutput.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants