sending signal and handling in a shared library

Hi Experts,

I am working on a shared library to provide some functionality.  I want to be able to set some attributes when this library is loaded and running in a process.  For example, I want to set the log level of my library based on some signals.  For example,  when the user wants to change the log level, he can change some attributes and notify the process somehow.  How can I detect this signal.  I am working on Linux.
ambuliAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Duncan RoeSoftware DeveloperCommented:
The common practice is to use SIGHUP to notify a process that it should re-read its configuration file. See for instance man 8 init(although init also has telinit q as an alternative).
Since they are asynchronous events, signals are inherently tricky to handle. However the API to handle them has improved over the years. Don't even think of using the original ANSI signal() function: here's what it's man page has to say
The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux.  Avoid its use: use sigaction(2) instead.  See Portability below.
So you are going to use sigaction() to declare your signal handling function (signal handler). You will notice from its man page that the handler can be declared as either an sa_handler() or an sa_sigaction(). Although it looks more complicated, sa_sigaction() is the portable one and I strongly recommend it.
As a general rule, the less a signal handler does, the better. This reduces the effort that has to be expended to deal with the possible  arrival of another (possibly different) signal while the signal handler is executing. What I'm saying here is that it would be ideal if you could have your signal handler simply set a flag (that a signal has been received), and that code which depends on the configuration should re-read it and clear the flag (when the flag is set).
You can re-read the configuration inside the signal handler, but this could lead to unexpected results (e.g. a piece of code that depends on 2 different config items might process one old and one new value).
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Duncan RoeSoftware DeveloperCommented:
Being in a shared library makes no difference, except the application should not use the same signal and nor should any other libraries it loads.
0
ambuliAuthor Commented:
Thank you very much hope for the good explanation. Much appreciated.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.