This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
RE: System-wide mutexes and pthreads
- From: "Robert Collins" <robert dot collins at syncretize dot net>
- To: "'Charles Wilson'" <cwilson at ece dot gatech dot edu>,"'Conrad Scott'" <Conrad dot Scott at dsl dot pipex dot com>
- Cc: <cygwin-developers at cygwin dot com>
- Date: Fri, 14 Jun 2002 00:22:10 +1000
- Subject: RE: System-wide mutexes and pthreads
> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
> Sent: Thursday, 13 June 2002 8:02 AM
> This reminded me of something....
>
> Robert -- once upon a time the idea was bandied about to create a
> "subcygwin" static library that used only native, non-cygwin calls to
> directly access the cygwin mount table and sort of duplicate the
> functionality of (only) these two functions from cygwin.dll:
>
> cygwin_conv_to_full_win32_path
> cygwin_conv_to_posix_path
>
> [I'm sure this code is already in setup.exe's codebase -- somewhere].
Well, something equivalent is. It's still getting worked on to be more
loosely coupled. The actual thread you are referring to was on a
different program that setup, but yes I do recall it. The goal with
setup is to produce a library that cygcheck can use to sanity check the
install, that encapsulates the program logic of setup. (i.e. package
listings, installed files, etc etc etc). This is also underway, although
I imagine that Chris will have a small hernia when I ask for cygcheck to
use the STL.
> Anyway, I lost track of what happened with this proposal. Was it
> decided that this was a bad idea, and that
> setup
> rebase
> strace
> cygcheck
> should all continue to duplicate cygwin-like path translation
> independently, or did the idea just fizzle for lack of volunteers?
Fizzled... Work on setup modularisation progress nicely given the list
of TODO's. Work on the idea of a specific library (which as I mention
above, was not targeted at cygcheck or setup) for mount point
understanding fizzled.
Rob