Re: System-wide mutexes and pthreads

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Conrad Scott wrote:

> I know all about the "I used it 'cos I could" feeling. It's a shame that the
> daemon isn't a pure win32 program, but I get the feeling that it will depend
> more on cygwin features as it develops, rather than fewer; for example,
> configuration or log files should obey cygwin naming rather than raw win32.

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]. 
The idea being so that non-cygwin programs -- like setup.exe and perhaps 
the eventual rebase utility -- could understand cygwin paths, while 
remaining "non-cygwin".  [I'm license agnostic here; if we want 
non-open-soure progs to interoperate with cygwin, then the above two 
functions must be re-engineered by someone who hasn't seen cygwin's 
code; that's a lot of work.  Personally, I'm only worried about 
open-source progs, so IMO the chinese firewall is unnecessary: use 
cygwin-inspired code, put it in a GPL'ed static library -- this way Red 
Hat's license is satisfied, and we get a *static* library that enables, 
for instance:
  setup.exe and rebase.exe to understand cygwin paths -- but without 
relying on cygwin1.dll itself.  This is a good and necessary thing for 
these two specialized programs.
  Ditto maybe strace.exe, cygcheck.exe (cygwin programs which do not 
depend on cygwin1.dll)

Now, OTOH, cygserver *could* use this library for path access, but why? 
 cygserver, by its very nature, will depend on cygwin1.dll -- so why 
not use it's path conversion routines.  No need to rely on setup's 
subcygwin.a.  I don't see why using cygwin1.dll from cygserver is a bad 
thing...

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?

--Chuck