Re: gthread-win32.c

[Hans Breuer <hans breuer org>]

At 11:05 14.05.01 +0300, Tor Lillqvist wrote:
>Hans Breuer writes:
> > Attached the first native gthread implementation for win32. It is mainly
> > plain mapping of one API to another, although in some cases I'm unsure
> > if it maps The Right Thing. Maybe I should have read a
posix-thread-book :)
>
>This is a Good Thing (I think), thanks! You probably should send a
>copy of this code to the gimpwin-dev list, too, in case there is
>somebody there with enough understanding of threading issues in GTK+
>on Win32 to check whether this works as good, better, or worse than
>the current version that uses (an oldish snapshot of) the
>pthreads-win32 emulation library
>(http://sources.redhat.com/pthreads-win32/).
>
>FYI: The newer releases of the pthreads-win32 library have different
>versions of the DLL for apps built with MSVC and SEH (Windows
>Structured Exception Handling), MSVC++ and C++ exception handling, and
>with gcc. 

Exception handling should be a no-issue with all the plain "C" code.
Or is there some magic in GObject to let the destructors be called
automatically while processing exceptions ? :)

>This is why I have kept using the pthreads-win32 snapshot
>from May 1999, it ignores those issues, and I haven't had to think of
>it ;-) (Like, what if the application is built with MSVC and uses SEH,
>but also wants to use the prebuilt gthread DLL that is built with
>gcc?) Any thoughts on these issues?
>
With C it doesn't matter, because the program would crash on any
exception. If pthread does provide only a C-Api IMHO it shouldn't
matter either, because excetions shouldn't be thrown accross
extern "C" function boundaries.

With C++ it would definitely make a differnce, because AFAIK most
of the binary exception processing isn't covered by the C++ standard,
as well as name mangling etc.

Just another argument for people who want to stay at C forever ;-)

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert