This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Daemon reviewer


Gary, will you have to time make some sort of comment on the code/design
quality in the next (say) fortnight?
If not, please say so.

Likewise, Egor, Corinna, you both showed interest in having a daemon for
various tasks, and we have a potential daemon, all it needs is peer
review. If you don't have the time to review the results of ourgroup
discussion last year, please say so.

Chris, please make (yet another :}) clear statement about what output
you want from a reviewer, what credentials you need them to have (ie
will any of Gary/Egor/Corinna do?) and please think about what the way
forward will when you recieve that input.

The diff for the daemon is 130K. Thats not a lot of code (under 4400
lines, including the diff headers and the not-to-be-included shared
memory and IPC code).

It's got unix pipe (win9x) and Named Pipe (winNT) support.
It's got secured tty handle passing.
It's got a object based request marshaling approach, allowing for easy
extension.
It's got partial support for process management (ie callback an object
when process foo  exits). (Not needed for the initial merge - part of
the shm code).
It's multi-threaded (with blocking IO to be safe on win9x).
I've been using it exclusively for MONTHS with no problems.

It's not perfect (what is), but it should not have any negative impact
on cygwin or cygwin stability when. It shouldn't affect Redhat clients,
or net users, unless they choose to run it. It doesn't disable anything
core, only enables better security, (potentially performance) and
functionality when it is running.

And this is the kicker:
I'm stopping maintenance the cvs branch unless one of two things happen:
* I get a clear indication of what needs to be changed for inclusion.
* I get the go-ahead to include the non-shm aspects of the code.

I can't afford the time investment maintaining a dead branch, and unless
one of the two above things happen,  I've got to consider it dead, with
no community support.

This isn't an ultimatum or anything silly like that, just a statement of
fact. The branch can stay there as long as needed, but I'll not be
changing it, unless I need a specific feature from HEAD.

Rob


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]