Hi Vincent, Alex,
I'm not a C programmer, so, could you please explain why fork() is the problem? I see this feature work this way:

1. Place "run external command" statement into "if" statement inside the filter or function, so it will be ran only on the specific updates/withdraws.

2. When update/withdraw message is arrived, BIRD runs external command, passes message details to it as environment variables and forks it. After fork BIRD is not blocked by child execution, so it will not be a performance impact.

Please clarify if I missed something.

2014-07-18 20:40 GMT+03:00 Vincent Bernat <bernat@luffy.cx>:

❦ 18 juillet 2014 18:01 +0100, Alex Bligh <alex@alex.org.uk> :

>> On 18.7.2014 10:50, Stanislav Datskevich wrote:
>>> So, this feature will not be implemented? I think BIRD will turn into
>>> BGP swiss-knife if it will be.
>>
>> I think, this sounds interesting to me. And it shouldn't be very
>> complicated to code it. I will look at it.
>
> Can I suggest you make the syntax such that a script is but one option?
> I can see a good case for (e.g.) triggering a little lua to run, which
> would not involve a fork() and be much faster. Clearly someone else would
> have to code that bit, but generalising this might be useful. This way
> you could get your lua to filter out 99% of things before running
> (e.g.) a script. We have some experience integrating lua things and
> whilst I can't guarantee it, we may be prepared to take a look.

Another way to avoid forking is to allow a long-running process to
receive data, either through a socket or by spawning it and
communicating with it on stdin/stdout.
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c