Re: glib win32 condvar implementation

Owen Taylor writes:
 > There was at least some (small) attempt to make the GLib thread API 
 > more easily cross-platform than pthreads. So, pthreads-win32 might
 > go through a lot of trouble of emulation that we don't need in some
 > cases.

But on the other hand, GThread-using libraries and applications
developed on POSIX might implicitly depend on behaviour that pthreads
guarantees, but GThread doesn't document. Such semantics can easily
have been ignored in gthread-win32. (See bug #331367, after some false
starts the insight is in the last comment.)

Using pthreads-win32 would at least mean we implement pthreads
semantics as well as possible, thus providing a better match to what
software ported from POSIX might expect.

 > How big is pthreads-win32?

-rwxr-xr-x    1 tml      Administ    60273 Jun  4  2005 /opt/pthread/bin/pthreadGC2.dll

   text    data     bss     dec     hex filename
  25860    3036     368   29264    7250 c:/opt/pthread/bin/pthreadGC2.dll

 > Are you considering depending on it as
 > an external DLL/dependency, or incorporating it inside gthread.dll?

As an external DLL, like intl.dll and iconv.dll.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]