3 ms·

If you free something that has a reference to it still what would be the effect? Can GC still free and then fault out on the reference, or does the free throw a

If you free something that has a reference to it still what would be the effect? Can GC still free and then fault out on the reference, or does the free throw an error (and you do a check while GCing?). If the later, can you do a free starting anywhere or do you need to have a good global state?

setr 7y ago
What's wrong with the first option? Runtime invalidates the pointer, and then just segfault on use and be done with it? It seems to me that if you're going to play with memory directly, it's reasonable for the generally-memory-safe runtime to throw out its guarantees on memory-safety
- zbentley 7y ago
  I think it's reasonable to want that in principle, but in practice it gets really messy. What if I use a library which returns me a manually-mis-managed pointer (either due to a library bug or me not setting up manual memory management correctly when initializing the library) which segfaults on read or write? That's kind of spooky behavior in a language that prides itself on simplicity. There are ways that could be done (for example by making the type system aware of whether or not something is hand-managed and potentially unsafe) but not without adding considerable complexity to the language and, presumably, the implementation.
  - Reelin 7y ago
    Doesn't your scenario essentially amount to asking what happens if you use a poorly written library that does bad things and it breaks your program in unexpected ways? That can happen in every language I'm aware of, regardless of safety guarantees. For Go, consider the unsafe.Pointer type. This commonly recurring idea that we need to somehow banish all insecurity and risk is flawed in my opinion. When safe is the easiest and most convenient way of doing something, it will generally be used. What we need are sane defaults, combined with explicit and unambiguous interfaces for when we do choose to take manual control. The real issues start to arise when a language exhibits unexpected behavior, when automatic memory management is opt-in instead of opt-out, and similar.
- privateSFacct 7y ago
  That was my question- first option seems simplest and fair. If you can write code and manually manage things that’s all on u.
arcticbull 7y ago
Rust's `drop<T>(_: T)` function is really neat in that it's basically an empty function. Since ownership of the argument moves to the drop function it explicitly leaves scope and gets torn down. You can do something similar for go where you have a function that marks your locally-scoped variable dead, the compiler can track to make sure you don't use it afterwards, and if it's not the last reference to the underlying, it's not deallocated. If it is, it gets culled immediately.
- erik_seaberg 7y ago
  The “toilet closure” also works. |_|()

setr 7y ago

What's wrong with the first option? Runtime invalidates the pointer, and then just segfault on use and be done with it? It seems to me that if you're going to play with memory directly, it's reasonable for the generally-memory-safe runtime to throw out its guarantees on memory-safety

zbentley 7y ago
I think it's reasonable to want that in principle, but in practice it gets really messy. What if I use a library which returns me a manually-mis-managed pointer (either due to a library bug or me not setting up manual memory management correctly when initializing the library) which segfaults on read or write? That's kind of spooky behavior in a language that prides itself on simplicity. There are ways that could be done (for example by making the type system aware of whether or not something is hand-managed and potentially unsafe) but not without adding considerable complexity to the language and, presumably, the implementation.
- Reelin 7y ago
  Doesn't your scenario essentially amount to asking what happens if you use a poorly written library that does bad things and it breaks your program in unexpected ways? That can happen in every language I'm aware of, regardless of safety guarantees. For Go, consider the unsafe.Pointer type. This commonly recurring idea that we need to somehow banish all insecurity and risk is flawed in my opinion. When safe is the easiest and most convenient way of doing something, it will generally be used. What we need are sane defaults, combined with explicit and unambiguous interfaces for when we do choose to take manual control. The real issues start to arise when a language exhibits unexpected behavior, when automatic memory management is opt-in instead of opt-out, and similar.
privateSFacct 7y ago
That was my question- first option seems simplest and fair. If you can write code and manually manage things that’s all on u.

arcticbull 7y ago

Rust's `drop<T>(_: T)` function is really neat in that it's basically an empty function. Since ownership of the argument moves to the drop function it explicitly leaves scope and gets torn down. You can do something similar for go where you have a function that marks your locally-scoped variable dead, the compiler can track to make sure you don't use it afterwards, and if it's not the last reference to the underlying, it's not deallocated. If it is, it gets culled immediately.

erik_seaberg 7y ago
The “toilet closure” also works. |_|()