Re: Mixing Glib::Thread and pthread_*
- From: Daniel Elstner <daniel kitta googlemail com>
- To: Andreas Volz <lists brachttal net>
- Cc: gtkmm-list gnome org
- Subject: Re: Mixing Glib::Thread and pthread_*
- Date: Thu, 18 Jan 2007 19:14:36 +0100
Am Donnerstag, den 18.01.2007, 18:34 +0100 schrieb Andreas Volz:
> > > Is Glib::Thread always implemented with pthreads? Also on the win32
> > > plattform? Do I get problem while porting my application to win32?
> >
> > Likely, yes. Though pthreads are probably more or less supported on
> > Cygwin, you'll most likely want to target mingw, which as far as I'm
> > aware doesn't offer pthreads.
>
> Ok, is there a way to find out the Glib thread model at runtime and/or
> compile time?
Well, unless you implement your own backend (Glib::thread_init() takes
an optional vtable argument which allows this), you can probably assume
it's using POSIX threads if that is available and more or less canonical
on the target platform.
But I don't see how knowing this could be helpful in your case. The
library you want to use will simply not work on mingw, as it uses
pthreads directly. Although, according to Google there is a
pthreads-win32 project out there:
http://sourceware.org/pthreads-win32/news.html
In order to use that, you would have to create your own gthread backend
though and pass it to Glib::thread_init(). Assuming, of course, that
the pthreads-using library you want to use actually compiles on Windows.
However, the g_thread_init() documentation is accompanied by this note:
Do not call g_thread_init() with a non-NULL parameter unless you
really know what you are doing.
I think you'll have to investigate the portability of gpsd before you
can decide on the proper route to take.
--Daniel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]