diff options
author | Christopher Faylor <me@cgf.cx> | 2012-06-03 22:02:45 +0400 |
---|---|---|
committer | Christopher Faylor <me@cgf.cx> | 2012-06-03 22:02:45 +0400 |
commit | 3143cb7c00fc1b6f4d75a83ac28f3bfbc5d2e658 (patch) | |
tree | fb4a3fbfc0eea1168646125aca7fd53478418b00 /winsup/cygwin/DevNotes | |
parent | ff80d22a7c3d0d330c2892686aa694a080b109cb (diff) |
* DevNotes: Add entry cgf-000011.
* fhandler.h (fhandler_base::refcnt): Delete.
(fhandler_base::inc_refcnt): New function.
(fhandler_base::dec_refcnt): New function.
* cygheap.h (cygheap_fdnew::~cygheap_fdnew): Accommodate split of refcnt to
inc_refcnt/dec_refcnt.
(cygheap_fdget::cygheap_fdget): Ditto.
(cygheap_fdget::~cygheap_fdget::cygheap_fdget): Ditto.
* dtable.cc (dtable::release): Ditto.
(cygwin_attach_handle_to_fd): Ditto.
(dtable::init_std_file_from_handle): Ditto.
(dtable::dup3): On success, return with fdtab locked.
* dtable.h (dtable): Add dup_finish as a friend.
* syscalls.cc (dup_finish): Define new function. Increment refcnt while fdtab
is locked.
(dup2): Use common dup_finish() to perform dup operation.
(dup3): Ditto.
Diffstat (limited to 'winsup/cygwin/DevNotes')
-rw-r--r-- | winsup/cygwin/DevNotes | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/winsup/cygwin/DevNotes b/winsup/cygwin/DevNotes index 778a5d059..a311256e2 100644 --- a/winsup/cygwin/DevNotes +++ b/winsup/cygwin/DevNotes @@ -1,3 +1,28 @@ +2012-06-02 cgf-000011 + +The refcnt handling was tricky to get right but I had convinced myself +that the refcnt's were always incremented/decremented under a lock. +Corinna's 2012-05-23 change to refcnt exposed a potential problem with +dup handling where the fdtab could be updated while not locked. + +That should be fixed by this change but, on closer examination, it seems +ilke there are many places where it is possible for the refcnt to be +updated while the fdtab is not locked since the default for +cygheap_fdget is to not lock the fdtab (and that should be the default - +you can't have read holding a lock). + +Since refcnt was only ever called with 1 or -1, I broke it up into two +functions but kept the Interlocked* operation. Incrementing a variable +should not be as racy as adding an arbitrary number to it but we have +InterlockedIncrement/InterlockedDecrement for a reason so I kept the +Interlocked operation here. + +In the meantime, I'll be mulling over whether the refcnt operations are +actually safe as they are. Maybe just ensuring that they are atomically +updated is enough since they control the destruction of an fh. If I got +the ordering right with incrementing and decrementing then that should +be adequate. + 2012-06-02 cgf-000010 <1.7.16> |