[Olsr-dev] Ignoring signals

Markus Kittenberger (spam-protected)
Sat Apr 10 21:07:47 CEST 2010


On Sat, Apr 10, 2010 at 8:59 PM, Mitar <(spam-protected)> wrote:

> Hi!
>
> On Sat, Apr 10, 2010 at 8:10 PM, Markus Kittenberger
> <(spam-protected)> wrote:
> > from my point of view, if you would make a patch i would have no real
> > problem with it *G
>
> Ehm. This is adding two lines where all other signal calls are:
>
we have a public repository, just push it, i guess no one will revert it *G

>
> signal(SIGUSR1, SIG_IGN);
> signal(SIGUSR2, SIG_IGN);
>
> > BUT i have some doubts if 2 signals are really useable for all the
> various
> > plugins,..
> > what happens if 2 plugins want to use the same signal?
>
> Then the last one will prevail when they register their signal handler.
>

yes, and a bad coded plugin might than stop olsrd from even starting? (in
theory)

>
> > i think any plugin that needs user interaction should do this differently
> > than with SIGUSRx
>
> Like? So we have a daemon running and would like simple mechanism of
> talking to it. Signals are often used for this.
>
sure, i would have no doubts if the olsrd core would use the signals *G

>
> But of course we could always add some abstraction to OLSR. Like
> registering some main signal handler which would call plugin's signal
> handlers one after the other.
>
i think when there`s another plugin that wants to use signals aswell this
would be something to go for,.. *G

>
> For now I think it does not hurt if OLSR does not get killed by USR1
> and USR2

i think so too,

and as nobody else sade anything,..
just do it!

regards Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100410/4d6be14c/attachment.html>


More information about the Olsr-dev mailing list