Let's look again at the pipeline example. Suppose we want to do the encryption twice (you know, maybe we have a secure channel to a semi-trusted intermediary who can can read the envelopes and forward the encrypted messages he can't read to the final destination). The pipeline becomes
decrypt | decrypt | process | encrypt | encrypt
Or if you want to think about it in a more function-like notation, rather than a pipeline, the logic can also be expressed as:
encrypt(encrypt(process(decrypt(decrypt(data)))))
However it would not work directly: a decrypt function has only one output and it can not have two bindings at the same time, it would not know which one to use at any particular time.
Instead you can make decrypt into a template, instantiate it twice, and connect into a pipeline. It's very much like what the Unix shell does: it instantiates a new process for each part of its pipeline.
But there is also another possibility: instead of collecting the whole pipeline in advance, do it in steps.
Start by adding in every binding:
withTray => 1,
This will make all the bindings collect the result on a tray instead of sending it on immediately. Then modify the main loop:
while(<STDIN>) {
chomp;
# receive
my $abReceive = Triceps::AutoFnBind->new(
$retReceive => $bindDecrypt,
);
$unit->makeArrayCall($lbReceive, "OP_INSERT", $_);
# 1st decrypt
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDecrypt,
);
$bindDecrypt->callTray();
# 2nd decrypt
my $abDecrypt2 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDispatch,
);
$bindDecrypt->callTray();
# processing
my $abProcess = Triceps::AutoFnBind->new(
$retOutput => $bindEncrypt,
);
$bindDispatch->callTray();
# 1st encrypt
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindEncrypt,
);
$bindEncrypt->callTray();
# 2nd encrypt
my $abEncrypt2 = Triceps::AutoFnBind->new(
$retEncrypt => $bindSend,
);
$bindEncrypt->callTray();
# send
$bindSend->callTray();
}
Here I've dropped the encrypted-or-unencrypted choice to save the space, the data is always encrypted twice. The drainFrame() call has been dropped because it has nothing to do anyway, and actually with the way the function calls work here. The rest of the code stays the same.
The bindings have been split in stages. In each stage the next binding is set, and the data from the previous binding gets sent into it. The binding method callTray() replaces the tray in the binding with an empty one, and then calls all the rowops collected on the old tray (and then if you wonder, what happens to the old tray, it gets discarded). Because of this the first decryption stage with binding
$retDecrypt => $bindDecrypt,
doesn't send the data circling forever. It just does one pass through the decryption and prepares for the second pass.
Every time AutoFnBind->new() runs, it doesn't replace the binding of the return but pushes a new binding onto the return's stack. Each FnReturn has its own stack of bindings (this way it's easier to manage than a single stack). When an AutoFnBind gets destroyed, it pops the binding from the return's stack. And yes, if you specify multiple bindings in one AutoFnBind, all of them get pushed on construction and popped on destruction. In this case all the auto-binds are in the same block, so they will all be destroyed at the end of block in the opposite order. Which means that in effect the code is equivalent to the nested blocks, and this version might be easier for you to think of:
while(<STDIN>) {
chomp;
# receive
my $abReceive = Triceps::AutoFnBind->new(
$retReceive => $bindDecrypt,
);
$unit->makeArrayCall($lbReceive, "OP_INSERT", $_);
{
# 1st decrypt
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDecrypt,
);
$bindDecrypt->callTray();
{
# 2nd decrypt
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDispatch,
);
$bindDecrypt->callTray();
{
# processing
my $abProcess = Triceps::AutoFnBind->new(
$retOutput => $bindEncrypt,
);
$bindDispatch->callTray();
{
# 1st encrypt
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindEncrypt,
);
$bindEncrypt->callTray();
{
# 2nd encrypt
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindSend,
);
$bindEncrypt->callTray();
# send
$bindSend->callTray();
}
}
}
}
}
}
An interesting consequence of all this nesting, pushing and popping is that you can put the inner calls into the procedural loops if you with. For example, if you want to process every input line thrice:
while(<STDIN>) {
chomp;
# receive
my $abReceive = Triceps::AutoFnBind->new(
$retReceive => $bindDecrypt,
);
for (my $i = 0; $i < 3; $i++) {
$unit->makeArrayCall($lbReceive, "OP_INSERT", $_);
{
# 1st decrypt
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDecrypt,
);
$bindDecrypt->callTray();
{
# 2nd decrypt
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDispatch,
);
$bindDecrypt->callTray();
{
# processing
my $abProcess = Triceps::AutoFnBind->new(
$retOutput => $bindEncrypt,
);
$bindDispatch->callTray();
{
# 1st encrypt
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindEncrypt,
);
$bindEncrypt->callTray();
{
# 2nd encrypt
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindSend,
);
$bindEncrypt->callTray();
# send
$bindSend->callTray();
}
}
}
}
}
}
}
This code will run the whole pipeline three times for each input line, and print out three output lines, such as:
>3639366536333263346635303566343934653533343535323534326336313632363332633332
37323635373337353663373432303466353035663439346535333435353235343230366536313664363533643232363136323633323232303633366637353665373433643232333332323230
37323635373337353663373432303466353035663439346535333435353235343230366536313664363533643232363136323633323232303633366637353665373433643232333332323230
37323635373337353663373432303466353035663439346535333435353235343230366536313664363533643232363136323633323232303633366637353665373433643232333332323230
If you wonder, what is the meaning of these lines, they are the same as before. The input is :
inc,OP_INSERT,abc,2
And each line of output is:
result OP_INSERT name="abc" count="3"
I suppose, it would be more entertaining if the processing weren't just incrementing a value in the input data but incrementing some static counter, then the three output lines would be different.
However this is not the only way to do the block nesting. The contents of the FnBinding's tray is not affected in any way by the binding being pushed or popped. It stays there throughout, until it's explicitly flushed by callTray(). So it could use the blocks formed in a more pipeline fashion (as opposed to the more function-call-like fashion shown before):
while(<STDIN>) {
chomp;
# receive
{
my $abReceive = Triceps::AutoFnBind->new(
$retReceive => $bindDecrypt,
);
$unit->makeArrayCall($lbReceive, "OP_INSERT", $_);
}
# 1st decrypt
{
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDecrypt,
);
$bindDecrypt->callTray();
}
# 2nd decrypt
{
my $abDecrypt1 = Triceps::AutoFnBind->new(
$retDecrypt => $bindDispatch,
);
$bindDecrypt->callTray();
}
# processing
{
my $abProcess = Triceps::AutoFnBind->new(
$retOutput => $bindEncrypt,
);
$bindDispatch->callTray();
}
# 1st encrypt
{
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindEncrypt,
);
$bindEncrypt->callTray();
}
# 2nd encrypt
{
my $abEncrypt1 = Triceps::AutoFnBind->new(
$retEncrypt => $bindSend,
);
$bindEncrypt->callTray();
}
# send
$bindSend->callTray();
}
After each stage its binding is popped, but the tray is carried through to the next stage.
Which way of blocking is better? I'd say they're pretty equivalent in functionality, and your preference would depend on what style you prefer to express.
No comments:
Post a Comment