Cygdaemon - planning
Elfyn McBratney
elfyn@cygwin.com
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--?
Elfyn
--
More information about the Cygwin-developers
mailing list