Re: Dealing with HANDLEs


adebaene@xxxxxxxxxxxxxxxx wrote:
I agree, the problem is not a technical one : It is perfectly ok to use
DuplicateHandle as long as you play along the rules, but that's not the
point...
The problem I noticed is about object model : It's just rather
unnatural that a "Process" class is copyable. If there were such a
class, I would expect than, when an instance is duplicated, a new
process is launched (forked) on the system, and I doublt that is what
the OP wants
"Process" is just an identity object, who shouldn't be copyable for
semantic reasons ; as Jake as said, if you need to put them in an STL
collection, use (smart)pointers.

Salut,

I have to agree with you on the principle of natural conception. I did
look back and see that he is working with processes.

The technique Jake and I were proposing works for other kernel-mode
objects like mutexes, semaphore, etc. As for processes (and thread),
you're correct - there are some semantic issues that cannot be
overlooked. In particular, once you start controlling the underlying
mechanism (pausing, etc.) then there are other issues.

But...if you are working with other synchronization objects like
events, etc... then the C++ copy/assignment framework using
DuplicateHandle works well.

-Le Chaud Lapin-

.

Relevant Pages

  • Re: Dealing with HANDLEs
    ... in debug it works fine. ... DuplicateHandle as long as you play along the rules, ... semantic reasons; as Jake as said, if you need to put them in an STL ... The technique Jake and I were proposing works for other kernel-mode ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Dealing with HANDLEs
    ... with copying a handle. ... DuplicateHandle as long as you play along the rules, ... The problem I noticed is about object model: ...
    (microsoft.public.win32.programmer.kernel)
Loading