Re: Patch: Thread safe obstack

[Herbert Euler]

Thank you for the suggestions.

> > Below is my patch to obstack
>
> gnulib provides for obstack the same API as glibc. It makes no sense for
> gnulib to provide a variant of obstack that has features that glibc does
> not have.
>
> Therefore the right place to post your patch is either the libc-alpha
> AT sourceware DOT org mailing list, or the glibc bugzilla
> http://sourceware.org/bugzilla/

OK.  Thanks for the correction.

> > I have trouble using obstacks with my threaded server, since obstack's
> > error handling is not thread safe.  It provides a user defined
> > function `obstack_alloc_failed_handler' to signal errors when
> > allocation fails, and this function can call longjmp instead of
> > exiting.
>
> There is nothing not thread-safe about this.

Perhaps I did not describe clearly.  If I have only one obstack, it is
certainly not involved in the thread safe problem.  But I have many
obstacks in my program, so I am having to choose one of them
accordingly.  In fact, I create one server object for each thread,
which processes the requests, and each of the server objects contains
an obstack for memory managing.  That is why I want to call
`obstack_alloc_failed_handler' with a user provided argument.

This might be a poor design, but I think restricting memory management
with obstack to object takes its own advantages -- memory managing
strageties are devided into many small units, so the designing of the
strategies is simplified.  Besides, memory errors in one object will
not cause memory errors in other objects, so debugging could be easier
too.

> > But I can only call longjmp with a global jmp_buf, since
> > this function is called with no arguments.
>
> There are at least three ways to have a function with no arguments react
> depending where it is called:
>   - Use thread-local storage. See function pthread_getspecific [1]. gnulib 
> has
>     a module 'tls' for portability.
>   - Create the function as a local function (function defined inside a
>     function); this is a GCC extension to the C language [2].
>   - The 'trampoline' library [3], part of ffcall [4]. This facility allows
>     to create functions depending on arbitrary data (not just depending on
>     the current thread).
>
> Bruno
>
> [1] http://www.opengroup.org/susv3/functions/pthread_getspecific.html
> [2] http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65
> [3] 
> http://www.haible.de/bruno/documentation/ffcall/trampoline/trampoline.html
> [4] http://www.haible.de/bruno/packages-ffcall.html

The first way seems to be the most appropriate one to my program.  The
second one, because it requires GCC or other compilers that support
the extension, is not that appropriate.  The third one requires more
libraries to be linked with and I do not want.  And I am not using
C++, so the fourth is also not very appropriate.

But I notice that the thread problem that I am dealing with is only
one of the problems in error handling with obstack.  The global
function `obstack_alloc_failed_handler' enforces over all obstacks in
a program in that they must handle allocation errors in a uniform way.

In my server program, all obstacks are in one type of object -- the
server object.  Although I have difficulties choosing one, but there
are solutions.

However, there are other cases where there is no solutions, or the
solutions are tricky.  For example, if two obstacks are in two
different type of objects which react differently to memory allocation
failure, using a global `obstack_alloc_failed_handler' is a bad idea.

So in addition to introduce user provided data as argument to error
handler, we should introduce user provided error handler to obstacks
too.  This sophisticated way, many obstacks can work with each other.

I will improve my patches and send them to proper places.

Thank you.

Regards,
Guanpeng Xu

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/