On 9/6/22 6:31 PM, frame wrote:
Well, of course it would be the fault of the programmer. I did ask this
because I just want to know if there is any catch of this (probably not
intended/yet noticed) violation of some third party lib. I don't want do
debug this :D
You can be confident that if
On Monday, 5 September 2022 at 18:35:02 UTC, Steven Schveighoffer
wrote:
On 9/5/22 7:12 AM, frame wrote:
And what if the programmer has no actual reference but wrongly
forced a `free()` through a pointer cast?
https://dlang.org/spec/garbage.html#pointers_and_gc
* Do not store pointers into
On 9/5/22 7:12 AM, frame wrote:
And what if the programmer has no actual reference but wrongly forced a
`free()` through a pointer cast?
https://dlang.org/spec/garbage.html#pointers_and_gc
* Do not store pointers into non-pointer variables using casts and other
tricks.
```d
void* p;
...
int
On Saturday, 3 September 2022 at 14:31:31 UTC, Steven
Schveighoffer wrote:
On 9/3/22 9:35 AM, frame wrote:
What happens if a manually `GC.free()` is called while the
forked process marks the memory as free too but the GC
immediately uses the memory again and then gets the
notification to
On Saturday, 3 September 2022 at 13:35:39 UTC, frame wrote:
I'm not sure I fully understand how it works. I know that the
OS creates read only memory pages for both and if a memory
section is about to be written, the OS will issue a copy of the
pages so any write operation will be done in it's
On 9/3/22 9:35 AM, frame wrote:
I'm not sure I fully understand how it works. I know that the OS creates
read only memory pages for both and if a memory section is about to be
written, the OS will issue a copy of the pages so any write operation
will be done in it's own copy and cannot mess up
I'm not sure I fully understand how it works. I know that the OS
creates read only memory pages for both and if a memory section
is about to be written, the OS will issue a copy of the pages so
any write operation will be done in it's own copy and cannot mess
up things.
But then is the
