On Sun, Sep 29, 2013 at 10:02 PM, Søren Sandmann <[email protected]> wrote:
> Andrea Canciani <[email protected]> writes: > > > I have some work on memleak related issues: > > > > > http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops-to-master&id=77db90242f7b7f12c5792480a10eb3a448e6c55f > > and > > > http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops-to-master&id=ca41228a66fe9bbec354cdef034c144ce1619793 > > > > Do you think it might be worth to revive it and cleanup for review & > merge? > > Unfortunately they depend on simpleops, a header-library I wrote to > > abstract (from compiler/platform) some low-level operations, like atomic > > arithmetics, mutexes, threads and library constructors/destructors. > > (currently all of them except init/fini are available in C11 and the > > simpleops API tries to be as similar to C11 as possible, to ease > C11-based > > implementations and to make it easy to get rid of the simpleops > dependency > > when C11 support is sufficiently widespread). > > Would it be ok to have it as dependency? > > At some point pixman probably needs to become multithreaded and then we > will need some abstraction for these low-level operations. > > I think I have mentioned before that it might be a good idea to have an > MIT licensed utility library that could contain these lowlevel > operations along with things like linked lists and growable > arrays. Linked-list and hashtables are available in http://cgit.freedesktop.org/~ranma42/simpledata I could add growable arrays, if this is blocking the adoption of this abstractions. > > Until simpleops grows into such a library, I think I'd prefer to > keep the abstractions inside pixman, though those internal abstractions > could potentially be based on code from simpleops. > These header-based libraries can easily (assuming the build process is autotools or win32-makefile based) be included as git submodules. (You might have noticed that they also provide some helpers for symbol visibility > > > There is also a general issue with header libraries: they have > potentialy complicated ABI issues because the code is inlined into all > users, so if any aspect of the code changes, you have to recompile > everything. > > Looking briefly at the simpleops code, I noticed a few things: > > - There doesn't appear to be support for __thread for thread local > variables. > Exactly. I tried to implement them, but having all of them working with the same interface proved to be a very hard task. For example, on Windows there seem to be some problems when dynamically loading libraries that use __declspec(thread) (this seems to be a known limitation, see http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx and http://support.microsoft.com/kb/118816 ) Instead, simpleops provides a C11-like thread-specific storage API. > > - It's a bit difficult to understand all the headers that include each > other. (The proliferation of headers is something that I never liked > about the cairo code as well). Would it be possible to just have one > header per platform -- ie., simpleops-win32.h, simpleops-posix, ...? > It should be possible, but there seem to be quite a lot of platforms, because sometimes the features are made available by the compilers (example: atomics on gcc and msvc) while sometimes they depend on the system library (example: threads). In addition to that, currently some common code is factored out and the files are structured so that they can be compared and extended (adding a new implementation or adding functions to all implementations) easily. All in all I believe it would be possible to have simpleops-win32-gcc.h simpleops-win32-msvc.h simpleops-mac-posix.h simpleops-suncc-posix.h and so on, but I'm afraid it would be harder to maintain. For an efficient way to view and compare the implementations, see file:///path/to/simpleops/index.html?atomic/impl/_dispatch.h (and similarly using "mtx", "cnd", and so on instead of "atomic") > - There is no way to statically initialize a mutex. I realize that > that's because Windows doesn't offer this feature, but without it, > you need some kind of library initialization routine. > Library initialization routine are provided, so you can use them both for mutex initialization and for TSS setup. A possible alternative would be to use something like call_once(), but it is pretty hard to perform the proper deinitialization upon library unload if you use that. > I wrote some notes here: > > > http://cgit.freedesktop.org/~sandmann/pixman/tree/docs/thread-primitives?h=docs > > about how you could emulate them on Windows. > Instead of static mutex initialization, your docs seem to be suggesting that call_once() should be made available. Would that be sufficient? How would you destroy/free that data that has been created/allocated in this initialization? Ideally I'd want to be able to load, use and unload pixman, cairo and any library repeatedly with no bugs/leaks/crashes. > > - If/when we get serious about multithreading in pixman, we'd likely > need support for condition variables, and on Linux possibly handroll > the thread primitives based on futex() and clone() without using > pthreads. > Simpleops already provides C11-like condition variables (cnd_{destroy,init,signal,timedwait,wait} are already implemented, cnd_broadcast is not, but it should be trivial to add it if needed). It should also be possible to avoid pthread and use syscalls directly, but why should that be needed? Is pthread very inefficient on linux? Andrea
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
