doodle at scenergy.dfmk.hu
Fri Aug 19 00:45:21 PDT 2005
There is a problem I don't yet know how to solve, that the usage of
mutex semaphores is built on pthreads. I thought I'll drop up the
problem here for discussion, so people will know about it.
Looking through the code, it seems that the font backends and the
xlib backend uses mutex semaphores to protect different stuffs from
concurrent access in a multithreaded environment. From these, only the
two font backends is important for me (for OS/2).
The problem is that pthreads mutexes can be initialized as simple
variables, putting a special value into them, which means that
pthreads mutexes can be initialized from data segment.
However, if one doesn't have pthreads, he has to use the semaphore
support of the underlaying OS. Under OS/2 (and in Windows too) there
is an API for creating, acquiring, releasing and destroying mutex
semaphores. Creating a semaphore requires a call to a given API
(DosCreateMutexSem() in my case), so semaphores cannot be initialized
from the data segment. (And still there is the problem that they
should be destroyed once, but there is no such thing in the current
Cairo way of using mutexes.)
Solving this would require way too many changes in the code, so I'm
not even hoping to have this done, but here is what I think should be
There is a need for a global cairo_initialize() and cairo_uninitialize()
API, which should call the private _initialize() and _uninitialize()
functions of all the backends, function packs, anything compiled into
the current Cairo binary, so they could set up everything they need in
order to start working.
Creation of mutex semaphores could be put to cairo_ft_font_initialize()
then, while destroying them to cairo_ft_font_uninitialize().
Any thoughts about it?
More information about the cairo