cygipc (and PostgreSQL) XP problem resolved!

[Charles Wilson]

Robert Collins wrote:
>>I take it you're in favor of adding cygipc to the distro (or are you 
>>speaking academically)?
> 
> 
> Frankly, I don't care whether it's in or not. The issues with cygipc
> getting integrated to the 'kernel', and with it fulfilling some corner
> cases wihtout such integration are moot while no-one has the time to
> progress cygdaemon's SysVIPC code. 

No, cygipc will never be integrated into the cygwin kernel.  It can't 
be, given the licensing issues -- it will always remain an addon 
package, whether 'in distribution' or outside (as it is now).

The issue is whether to make the cygipc package a full-fledged part of 
the cygwin world, distributed via the mirror system -- like zlib, 
libxml, postgresql, etc -- instead of from some schmuck's personal 
website (e.g. mine).

> And heck, so far cygdaemon does the tty security thing that was it's
> original requirement, as well as all the shm functions, all the key
> functions, and some of the sem functions. All with security set
> correctly on NT, and via mode_t values on 9x. Fork safe. Dirty process
> aborts were mostly handled (which I don't think cygipc handles at
> *all*). 

Rule of thumb: cygipc sucks.  That's (one of the reasons) why I resisted 
adding it to the distribution.

> Conceptually it was multi-user ready (i.e. run with 'switch
> users' or Terminal Services safely). 
> 
> From memory cygdaemon had to be 80% complete when I handed over
> maintainership. I simply didn't have time to complete it. 

I understand.

> I've no idea whats happened since, as I haven't been tracking commits to
> it - the exact same lack of time that prompted me to step down as
> maintainer.

Conrad Scott provided some patches, but he disappeared abrubtly last 
September.  Nobody has been able to contact him at all since then, AFAIK 
-- and I've tried.  Since his disappearance, IIRC nobody has patched 
anything in the cygdaemon code.

> Again, IIRC, it was slower than cygipc at the time - but *no*
> performance tuning had been attempted, so I don't find that surprising.

Sure it was slower -- cygipc is fast and dirty, and does a lot of things 
wrong.  But quickly.

> Given the above, it should be clear that IF I had the time do some
> something about it, I'd finish off cygdaemon, and THEN I'd have the
> right to an opinion about cygipc coming into the distribution.

Disagree.  You have as much right to offer an opinion as anyone else, 
regardless of whether you did/will/won't/intend to fix cygdaemon.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/