This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: UWIN not supported
- From: Ross Johnson <Ross dot Johnson at homemail dot com dot au>
- To: pthreads-win32 at sourceware dot org
- Cc: spongelavapaul at mac dot com
- Date: Mon, 21 Apr 2008 15:00:17 +1000
- Subject: Re: UWIN not supported
- References: <A0ACF27B-F664-40A9-B391-32DAB83D2B1E@mac.com>
Paul Thomas wrote:
I read in the announcement (POSIX Threads (pthreads) for Win32) that
UWIN is not supported. What does that mean exactly? Does it mean that
the two won't work together or just that nobody wants to look into any
In the most general sense it means that I don't run the test suite
against any UWIN build of the library before releasing revisions.
Several years ago now, I wasn't able to get the UWIN environment up and
running and haven't had the interest to spend more time on it. I'd be
happy to change the ANNOUNCE file if someone is willing to confirm that
the [pthreads-win32] test suite passes - or passes with known exceptions.
As you've indicated, signals don't work, nor does shared memory etc. and
AFAIK UWIN would need to be made threads-aware for these to work as well.
I assume they have worked together at least superficially in the past,
hence the UWIN sections in the source (contributed by David Korn at
AT&T). But to what extent they worked together back then I don't know.
With minimal effort, someone who knows UWIN internals could probably get
it working well enough to get through the pthreads-win32 test suite, but
real applications that also need what UWIN provides, e.g. signals, still
may not work.
Not sure if this helps at all but, ultimately, IMO UWIN needs it's own
pthreads routines as Cygwin has done.