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]

cygwin daemon/shm


In this tarball:
* a minor newlib sys/types.h change, based on the ieee recommendations,
to make key_t as big an int possible. Note: as the only use for key_t is
in non-realtime IPC, this should break precisely one app: cyg_ipc, and
anything built on it.
* a cygwin directory patch, to put the hooks in for using the daemon.
Other than the Makefile, and the exports for ipc & shm, this hasn't
changed in my last two snapshots IIRC - ie it's stable.
* the working files:
cygserver.cc (the daemon main, and server_request class)
cygserver_client.cc (cygwin hookin.)
cygserver_shm.cc (shm interface for the daemon
cygserver_shm.h
cygserver_transport.cc (winsock transport for the daemon - win95)
cygserver_transport_pipes.cc (named pipes transport for the daemon - nt)
ipc.cc (_basic_ IPC implementation I created about a year ago. Not
complete. - When I realised the need for the persistent daemon, it got
put on hiatus)
shm.cc (the beginnings of the shm implementation. specifically shmget
and shmat)
include/cygwin/cygserver.h (global header file for using the daemon.
Egor had this here, and I figured that things like XFree86 may desire
direct access to the daemon (ie for high efficiency clipboard
manipulation). No reason other than that preventing it being moved to
the cygwin dir.)
include/cygwin/cygserver_transport.h (the class definitions for both
winsock and named pipes. This should be tweaked for cleanness (winsock
is currently the base class) *shrug*.)
include/sys/ipc.h (have a guess :])
include/sys/shm.h

also attached to the email, some trivial ipc test programs I created way
back.

I believe this forms a reasonable base for a integrated daemon, and one
that will meet the criteria put forth by Corinna (and I'm assuming they
are correct because there was no argument about them :}...)

For the memory impaired they where:

1. Platform independent (from a Wincentric point of view, 9x/NT)
This is. I've tested it on Win2k and 95.
2. Fast
Should be, it's aggressively multi threaded, using thread pools for
efficiency, and as the pool class has no globals, can be extended to
multiple pools for different requests queues if and when it needs that.
3. Reliable
I haven't managed to make it break. Doesn't say too much though :}.
Testing testing testing. It's using sockets for 9x, and pipes for NT, so
it should avoid the nasty pipes-on-95 headaches, and I'm not aware of
problems with pipes on NT...
4. Secure
The transport layer includes core impersonation functions. For winsock
we can use the GSSAPI to get impersonation capability, if anyone wants
to make NT use sockets rather than pipes, but by abstracting the
transport, there was no problem using different base layers.
Alternatives such as DDE for 95, or pipes+shared memory on NT are also
easy, I believe the abstraction covers everything of import. (except
addressing the target, thats hardcoded in the class for simplicity...)
5. Easy to use
It should be very easy to use. I'll write some doco once I've had some
sleep - if there is interest, but the basic recipe in cygwin is

class client_request_my_function *req = new client_request_my_function
(parameters);
int rc;
if ((rc = cygserver_request (req) == -1))
  {
    /* daemon isn't running or some comms failure occurred. */
  }
/* daemon message exchange happened ok, examine req for details */

The classes are _very simple_. All they need is a virtual function
serve() and two constructors - one that takes parameters, and one that
doesn't. I'd like to alter the cygwin side interface to be more class
orientated (req->do ()), but time hasn't permitted, and thats certainly
not a show stopper (there's only 4 API calls today, so it can tweaked as
needed.

As far as having things like
shm.get() within cygwin, that becomes trivial once the calling mechanism
becomes a method. The HL class simply instantiates the appropriate
message class and sends that. Or alternatively, the HL class can just
have a really big union, and one request id.

6. Expandable
Add classes. Ok, next. :]

I realise with the recent make-is-dead problems, that no-one may have
had time to look at this. If and when you do, please realise that this
is a _base_ not a finished production ready no bugs server :]. Also the
shm and ipc stuff is really crude. I'd only spent about 5 hours on it
last time around, and it got a radical restructure for this, it'll look
a lot cleaner and smaller when it's production ready.

Knowing how these things work, I'd like to propose one of the following:
a) when 1.3.3-3 or 1.3.4 (the thing with a make death fix/improvement)
goes out the door, and we have a little breathing space, this daemon
gets committed (subsequent to general file/directory layout discussion
and rearrangement as Chris requested). The shm and ipc functions _do
not_ get exported from cygwin, or they simply are not included in the
commit. (The goal is to add the daemon, not the tty_attach code or the
shm code per se).

It's then there, and able to be used when "If only we had a daemon" is
heard.

b) we branch cygwin, and checkin the daemon, shm the lot. (Subsequent to
the same layout discussion as in a) ). That then gets examined and
tweaked, and if-and-when folk are happy bits of it get merged to HEAD.
(I.e. the daemon might come in first, with no functions. and then we add
foo/bar..)

What I don't want to see happen is this bitrot. I'm happy with the
daemon+message passing+mostof the calling api, so I don't intend to be
tweaking this much.

In case you are wondering why I got off my chuff and did this? I was in
danger of falling into the "gee this would be nice" mode again, and
though I'd get out of danger.

Rob

daemon_shm.tar.bz2

ftok.c

shmat.c

shmget.c

shmgetexisting.c


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