-
Notifications
You must be signed in to change notification settings - Fork 144
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
Recurrent Connections in processes exhibit strange behavior on .run() (non-terminating) #32
Comments
Perhaps there's a bug in Lava but the first issue with the code above is this: This will block by design in case of a recurrent connection! When run_spk starts executing, it will block on recv() until there is input on s_in . In case of a serial connection, this won't happen because the port sending data belongs to a different independent process running in parallel. So nothing will block in this case. |
Yeah that seemed to solve the issue. Thanks! Maybe if there's a tutorial on this in the future we state this explicitly as a warning so that it saves time for other people :) |
Yes, we should probably create an FAQ with common/possible answers to "Why does my code deadlock?" when writing asynchronous code. |
A process (can be hierarchical or sub) when connected recurrently doesn't terminate after the process.run() command. The same process can be connected to another process serially and run without problems.
A minimal example for this behavior is detailed below. Two process are created where process 1 has one InPort and one OutPort and process 2 has only an InPort. Initially process 1 is connected to itself and run. This leads to non-terminating behavior. Also, the get() function to inspect the process variable leads to non-terminating behavior. The same process can be connected to process 2 and run without any problems. The problem appears to be recurrent connections for processes. The same behavior was observed for hierarchical process that housed sub-processes with recurrent connections (not shown in code below). The code that demonstrates the behavior I described above is given below. It has been commented to make the issue clear. @joyeshmishra
The text was updated successfully, but these errors were encountered: