Cygdaemon - planning

Elfyn McBratney
Thu Jun 26 17:10:00 GMT 2003

On Wed, 26 Jun 2003, Robert Collins wrote:

> On Thu, 2003-06-26 at 02:53, Elfyn McBratney wrote:
> > I'm going over my work on the Cygwin daemon and concepts for future features and
> > I just wondered if anyone had any thoughts on these?
> >
> >  - cygdaemon heap
> >
> >    A linked node (struct) list of raw memory. I have an implementation working
> >    now used to store security attributes, daemon info and security (logon)
> >    tokens. As it's a memory/next type list(s) it's easily used, just by casting
> >    to and from different types.
> I'm confused here. A heap is a specific structure, requiring an ordering
> on it's nodes, and usually implemented on top of an array. Also, in C++
> you should avoid casting where possible - it leads to (subtle) alignment
> errors unless you are using RTTI. In essence, I'm not sure quite what
> you are trying to achieve with this 'cygdaemon heap'. It sounds like you
> would be better off with an associative container of some sort, or a set
> of separate containers.

Yes, I've been compiling this piece of code with RTTI. It was just an
improvement on a staticly numbered array of structs (that I started out using).
This was allocation, re-allocation and free'ing is all dynamic.

> >  - ipc/sem/shm
> >
> >    as the ipc and shm code is pretty much complete, all it needs is final
> >    touches and the implementation of semaphores, which is not that hard. I have
> >    shm{ctl,op,get} mostly complete but it's in a mess as I;ve not touched it in
> >    months. IMO, this should be the first thing to be worked on and exported.
> Cool
> And Chris, re:
> > What is the rationale for putting things in a winsup directory?  Can't
> > cygdaemon
> > be in it's own sibling directory with winsup?
> While cygdaemon is tightly coupled to the internals of cygwin, I don't
> see any benefit in moving it out of winsup. Of course - it could be
> anywhere, even in a separate CVS repository - but --why--?


More information about the Cygwin-developers mailing list