Re: thread support in Windows: problem

["Tor Lillqvist" <tml iki fi>]

> I am trying to run a simple(st) thread example in GTK with a
> windows-MinGW-Msys development environment

Don't bother. You should not call GTK+ functions from multiple threads
on Windows. It won't work. There are deep technical reasons for this,
fixing it is in no way trivial. This has been mentioned several times
over the years on this mailing list.

Only call GTK+ functions from the thread (usually the "main" thread)
that runs the GLib main loop, i.e. that calls gtk_main().

(Well, some limited (unknown) subset of GTK+ calls might work if
called from other threads than the main thread. You have to experiment
yourself.)

> Mingw unfortunately doesnt provide thread headers
> and libraries[pthread.h is unavailable].

Mingw provides the API for the native Win32 thread API and the
Microsoft C library thread functions in its header just fine. That is
what it should do. Mingw is not about POSIX emulation. The "p" in
"pthread" stands for POSIX.

That said, there does exist a good implementation of the pthread API
to Windows. (It wraps the native Win32 thread API.) Google for
pthreads-win32. You probably found it already? (That doesn't change
the situation, though. Using GTK+ from multiple threads won't work on
Windows no matter what API you use to create the threads.)

But anyway, why don't you use the GThread API, which might be more
natural in a GTK+ program. (But I repeat once more, using GTK+ from
multiple threads won't work on Windows no matter what API you use to
create the threads.)

> I have copied the headers[pthread.h, sched.h
> and semaphore.h] into the mingw include folder, and I have copied the
> libraries for threads all into mingw lib folder.

Without central package management (like on Linux), it is a bad idea
to mix stuff from different origins in the same tree. Don't copy
headers and libraries around so that you end up with a multitude of
copies here and there. It will only confuse you later when you perhaps
decide to upgrade to a fresher mingw and blow away the old mingw tree,
forgetting that you had added other stuff there.

Keep only what the mingw project distributes in the mingw tree, and
things downloaded from other places in some systematic way in specific
trees. Use -I and -L flags as appropriate when building, and set PATH
when running.

> I even use a -Lpath during compilation of my thread application.

Well, d'oh. Using -L flags are a very basic thing.

> Program compiles but the executable fails to link to the downloaded libraries
> [which I have supplied in the -L and l options to gcc].

Do you know the difference between "import libraries" and DLLs? When
using DLLs, the libraries you specify when linking with -l are
(typically) import libraries. These aren't used at run time. The -L
switch has no effect on where the executable looks for DLLs at run
time. Nor has any other switch you can give at link time. Unlike most
Unix systems, on Windows one can't store in an executable's header any
run-time look-up path for shared libraries.

> Message tells me "dll not found".

You need to read up on how Windows locates DLLs required by a starting
program. Hint: PATH.

> I thought it might have something to do with registering the DLL with the
> OS, and so I used regsvr32 to get DLL registered, but registration somehow
> failed[I am not a geek and so I was not able to figure out why it failed].

Registering DLLs is related to COM and/or OLE, and has nothing to do
with normal DLLs.

> DISCLAIMER

Please stop attaching multiple copies of the ridiculous disclaimer to
your messages. It doesn't improve your credibility.

--tml