What "Signal Sockets" Are For And How They Are Processed
To introduce conditional graph traversal into workflow (for example, to introduce cycles), one can use sockets typed "signal." In addition to classical "signals," connections associated with these nodes allow passing any type of data if your use case requires that.
In short, pxWorks uses just one rule for graph traversal:
So the difference between non-signal and signal (non-conditional and conditional) input sockets is that conditional input sockets require an existence of a file to activate the code and non-conditional nodes should ALL be recalculated for a dependent node to activate, while it only requires one conditional node to send a signal to activate a dependent node.
Non-conditional nodes are nodes connected to regular (non-signal) sockets. The success of the run is signaled by state "ready" and green light on a block.
Conditional nodes are nodes connected to sockets of type "signal." The code that is run by the block that has an input socket of type 'signal' may delete or move the signal file from the source node. If the file is not deleted, then the block will get activated again if the graph has a cycle.
If more than one "signal" files are generated simultaneously (as detected by pxWorks), then the dependent block will be run only one time. Therefore, it is up to the user to process all the input socket files and detect which particular signal file (or files) has (have) been generated and treat them as programming logic requires.
Definition Of Sockets Tagged as "Signal"
Signal sockets can only be input sockets and are defined in plain text files as follows.
{signal_socket_name}{space}"signal"
{signal_socket_name}{space}"signal"
Each socket must be defined on a separate line.
Concluding Remarks
To pass a signal from one block to another, one must create a file with the name of the output socket. After the file is generated, the environment will detect that a file has been generated and will activate the block to which that file is connected through a socket of type "signal." If no file is generated, then no activation will occur. The contents of the file can be absolutely arbitrary, including absence of any data in the file (i.e. the size of the file might be zero). As long as the file itself is present, activation of the block to which it is connected will occur.
The block receiving the signal can delete the signal file to prevent being activated by it after the code has been run.
Blocks with inputs consisting of only signal type sockets will be activated only when a signal file is present.
Finally, this is how the links that connect signal sockets look -- magenta colored lines.
This screenshot has been made off the project currently included in the archive with the software. Its main purpose was to test signals and stress test the system in general. All the components are included in the default library. Feel free to tweak the code and let us know what you think.
Thanks for this information, it was userful cause now i know exactly what signal sockets are for.
I found your this post while searching for some related information on blog search, Its a good post..keep posting and update the information.
This post is very helpful to me I found this post while searching on google, this is remarkable.
Before using anything, we need to know its pros and cons so that we do not have to worry about it later. I am glad to know about what "Signal Sockets" are for and how they are processed.
