13.10.2013 21:36, Robert пишет:
* Robert's one from his new `std.signals` implementation proposal:
https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d
Obviously I don't see it, otherwise I would have fixed it. Maybe you
could elaborate a bit on your claim? Your implementation uses an
entirely different technique for hiding the reference so a direct
comparison is quite hard.
1. Have you read `gc.gc.fullcollect`, I mean a general function
structure, not every line? If not, read it or you have no idea how
collection performs.
2. I'm surprised you do think your implementation is correct as calling
code twice (`foreach(i; 0..2)`) is an obvious hack to decrease a variety
of undesired threads execution order (as it have to execute in this
order twice).
----- Explanation -----
1. Race condition
In every moment GC thread can be paused in state it already marked
all dead blocks and ready to collect. So before `GC.addrOf` (which will
have to wait for the end of the collection as it uses same mutex) call
it can collect your object (the object can be on stack or whatever,
doesn't matter). Also an new object can be created occupying the same
memory and `GC.addrOf` will return non-null.
2. Incorrect assumption
`o = GC.addrOf(tmp.address)` is just incorrect as you assume the
object is placed at the base address of its memory block which is not
guaranteed. Yes, it may be true for now (I haven't read GC sources
enough to be definite here) in general case but what about some e.g.
tricky user defined class instance sequences which user may create? Yes,
never heard about it and just invented it, but it doesn't make this or
similar case impossible. Also it's rather bad to do any needless
assumption about internal stuff.
----- P.S. -----
I have to say you have a big problem especially for a programmer: you
think you are competent in area you aren't and it can play a trick on
you later. Please don't be angry with me, we all like to think so but we
all have to look at ourselves as critically as possible to prevent
problems in future.
--
Денис В. Шеломовский
Denis V. Shelomovskij
