This is the mail archive of the cygwin-patches@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]

getting there.


This is nearly complete.

The list of things I want to do before I'll consider it finished
includes:

* finish making the request structs and marshaling more OOP based. (The
server request logic is now satisfactory to me, but the actual
marshaling and code select isn't making use of OOP).

These two things:
* persistent connections between daemon and client, with the main loop
performing select() (for sockets) and WaitforMultipleObjects for pipes,
and then assigning the ready conns to a pool of threads. This will
reduce connection/disconnection overhead and thus improve performance.
* on the client side, run one connection per thread, (needed for thread
safe performance).
are optional from a "testing and using point of view". That is to say
that not implementing them will have no negative impact on development,
but that implementing them will bring a performance benefit and should
be done before a .dll with a daemon (of any sort) is released. (Think
HTTP/1.0 vs HTTP/1.1 in efficiency).

You're welcome to criticise and so forth, just bear in mind the above
list (and of course, say if you think that something up there is
inappropriate).

The attached tarball has a patch against cvs, and a set of files to add
to the working dir.

The daemon currently does the following:
* on 9x uses AF_UNIX sockets for communications
* on NT uses named pipes for communications.
* Uses a persistent thread worker pool to handle requests. The resource
requirement of the daemon will _not_ grow if the number of cygwin
process's explodes out of control. I think the daemon should auto tune
(look at request rate, and add more threads if needed) but for now, 10
concurrent requests is plenty IMO. (Given that the requests are
extremely shortlived. I actually expect that you would need a dual
processor machine to use more than 2 threads at a time :})

In short, folk, you wished for a daemon, so here's a daemon. The class
hierarchy may not be _just right_ but it should certainly allow trivial
implementation of the various wishlist attributes of a daemon (ie
Service on NT, security etc).

Thanks go to Egor for providing the basis for this little beastie.

Rob

daemonstate2.tar.gz


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