Seth M. Landsman wrote:
> <<- snipping stuff about how to make a shared library ->>
>
> That does answer my question. I do have a follow up. Libraries,
> in general, should go out of their way to be reentrant and thread-safe
> (I'm hoping the "why" is obvious to the audience on this list, but I'll
> go into further detail on the topic if necessary).
>
> So the question on the floor is, what kinds of tricks and gotchas
> are there to look out for. I know of a few, but I'm sure my list is not
> complete (i.e., avoid globals, and if you must use them, make the
> operations atomic)
Libraries are just repositories of functions. There shouldn't be any
difference between writing code for a shared library and writing code
that just gets compiled to a .o and linked statically. The only
gotchas are the ones that apply equally to any code.
For thread-safety, apart from avoiding static variables, there's also
the issue of avoiding anything that uses static variables, and
sometimes explicitly using thread-safe functions e.g. using
gethostbyname_r instead of gethostbyname.
Also, you should define the _REENTRANT macro, which affects the way
that certain things are defined in the libc headers, e.g. errno is
defined as
#define errno (*__errno_location ())
so there's a different `errno' for each thread.
The main difficulty is knowing whether a particular function is
thread-safe or not. glibc-2 itself is generally thread-safe (if you
compile with _REENTRANT, and avoid functions which are inherently
non-thread-safe), but many other libraries aren't. Only recent
versions of Xlib are thread safe, and I'm not sure about Xt/Xaw/Xm.
--
Glynn Clements <[EMAIL PROTECTED]>
