Thread: Shared Library creation tips

I'm creating a shared library for the first time and would appreciate it if someone could provide a little guidance. Specifically, are there any special considerations I should be aware of? I'm compiling on Solaris 9 on a sparc station.

One more... I have a timeout mechansim using signals:

Code:

void timeoutAlarm()
{
   variable1 = value1; variable2 = value2...
   exit(1);
}
...
signal(SIGALRM, timeoutAlarm)

where I want to return to the calling program when the timeout expires. My fear is that having an "exit(1)" in the timeoutAlarm() function will cause the calling program to exit instead of just returning to the calling function/program with the other stuff set in timeoutAlarm. Is this fear founded? If so, how would I accomplish this? Are there other alternatives?

Thanks!

The exit() function will cause the program to terminate. If you are just trying to return to the calling function, then why not use the return statement? I might have misunderstood your question a little bit.

Also, as a side note...
The only values you should pass to exit() are EXIT_SUCCESS, or EXIT_FAILURE. You can also pass 0 which is the same as EXIT_SUCCESS.

Sorry if I was vague. Here is a more concrete explanation...

I have a set of functions that I want to include in a shared library. I have a timeout mechanism for each of these functions. Given the following...

Code:

int timeoutAlarm(int n)
{
   return;
}

int otherFunction()
{
   signal(SIGALRM, timeoutAlarm);
   alarm(10);
   ...
}

Now, if the otherFunction() function is called by an external program will the return in timeoutAlarm() return to that calling program? Or just to the otherFunction()?

Thanks for the clarification. (I know what I hope the answer is because it will make my life that much less complicated!)

the problem I see with continually checking a global "timedout" variable is that if the alarm signal interrupts a function that is waiting on network i/o (for example) and simply returns it back to that interrupted function, then it may take several moments to complete the (network i/o) transaction (if it completes at all) before moving on to the next command - which would be my first opportunity to check the global variable. (or am I missing something regarding signal handling?)

If the network i/o is a problem then I would like to simply cut my losses and return to the calling function instead of being dependent on that transaction completing.

I'm guessing that this is not an uncommon scenario. I welcome any ideas and suggestions.

Cool. I'll run on the assumption that the signal will interrupt the current command/function and return to the calling function where I can then evaluate the global variable... unless I hear otherwise.

I'll have to add a bit of overhead to my remaining function calls to perform this evaluation, but I think that it will give me the desired functionality. Thanks for the input.