Re: [go-nuts] Is this implementation of weak pointers safe?
On Sunday, September 30, 2018 at 6:53:47 PM UTC-5, Dave Cheney wrote: > > Please don’t take os.File as justification, it’s one of the few uses of a > finaliser in the std lib. If it were being written today I would argue that > instead of silently closing the file, it should panic if the resource falls > out of scope unclosed. > > As always, remember that finalisers are not guaranteed to run as they are > tied to the gc cycle. In a well tuned application a finaliser can easily be > delayed until the resource they are meant to mediate has been exhausted by > overconsumption. > > Dave Panicking at runtime isn't really a thing that a library should do, especially when it's not tied to an action the program has taken in the immediate past. I've taken the middle ground, having the finalizer print a message to stderr if it needs to close a session. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
Please don’t take os.File as justification, it’s one of the few uses of a finaliser in the std lib. If it were being written today I would argue that instead of silently closing the file, it should panic if the resource falls out of scope unclosed. As always, remember that finalisers are not guaranteed to run as they are tied to the gc cycle. In a well tuned application a finaliser can easily be delayed until the resource they are meant to mediate has been exhausted by overconsumption. Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
On Sunday, September 30, 2018 at 4:56:20 PM UTC-5, Kane York wrote: > > In Go, it's usually better to use source code analysis to look for > forgotten Close calls, like the existing tooling for os.File (which does > have a finalizer, but doesn't need to). *os.File has a finalizer for the same reason that this code needs one - it holds onto an external resource with some kind of ID that needs to be closed manually through an API call. Even though runtime.SetFinalizer doesn't guarantee the finalizer will be called, the only reason it wouldn't be called is if the memory wasn't garbage-collected before the process exits (or the computer is unplugged, etc). In a long-running process, that isn't an issue for finalizers that just do cleanup. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
In Go, it's usually better to use source code analysis to look for forgotten Close calls, like the existing tooling for os.File (which does have a finalizer, but doesn't need to). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
On Sunday, September 30, 2018 at 4:00:32 AM UTC-5, Tamás Gulácsi wrote: > > 2018. szeptember 30., vasárnap 6:20:37 UTC+2 időpontban Ben Lubar a > következőt írta: >> >> On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: >>> >>> Quoting Ben Lubar (2018-09-29 14:40:28) >>> >[1]https://play.golang.org/p/iBAii-f84Sq >>> >vet is complaining because the unsafe.Pointer usage would normally >>> be >>> >dangerous around the garbage collector, but since I have a >>> finalizer on >>> >the "real" pointer and there is no way the code could access the >>> >uintptr with the same value as the real pointer once the finalizer >>> has >>> >run or been removed by Close, shouldn't this code be safe? >>> >>> From the unsafe package's documentation: >>> >>> > Even if a uintptr holds the address of some object, the garbage >>> > collector will not update that uintptr's value if the object moves >>> >>> One valid implementation strategy for a garbage collector is to do arena >>> allocation, and on a GC pass copy all *live* objects out of an arena >>> into another one for longer-lived objects, and then free the old arena. >>> In this case, your uintptrs would still still contain the old addresses, >>> even though the objects have moved. Note that the finalizer is never run >>> in this case, because the object has been moved without being garbage. >>> >>> Whether what you're doing is actually safe depends heavily on the >>> implementation details of the garbage collector. It may or may not >>> be possible for it to break given the current implementation; >>> I don't know enough about it to be sure. But a correct implementation >>> of the runtime could very well corrupt memory given the code you >>> linked; even if it works now, it's possible in a future release of >>> Go this could break. >>> >>> Hope this helps, >>> >>> -Ian >>> >> >> Is there any way to implement this safely, or should I just give up on >> the weak pointer idea? >> > > > What will your *Session keep from getting collected if you have only weak > pointers to it? Nothing. > > What are you trying to achieve? > > You have Session.Close. Why not have it clean up after itself - even from > the session registry? > Just have a "sessions=make(map[SessionID]*Session)", and do a > "sessionsMtx.Lock(); delete(sessions, sess.id); sessionsMtx.Unlock()" in > Session.Close. > > A WeakValueMap would eliminate the need of this explicit cleanup, but we > don't have weak maps in Go. > And Finalizers are totally unreliable - you don't know when will they be > called, if called at all. > Even if the finalizer is never called, it still holds a reference to the pointer, so the session won't be garbage-collected before then. The only thing the weak pointer lets me do is write a message that will hopefully be seen by the developer if they forget to close the session. The finalizer closes the session anyway, so the weak pointer never exists when the thing it points to doesn't exist. Another way I could theoretically do this is decouple the session from its data and store the data in the map but not the session object. That way, the session object could still be garbage collected even if the data is still in the map. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
2018. szeptember 30., vasárnap 6:20:37 UTC+2 időpontban Ben Lubar a következőt írta: > > On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: >> >> Quoting Ben Lubar (2018-09-29 14:40:28) >> >[1]https://play.golang.org/p/iBAii-f84Sq >> >vet is complaining because the unsafe.Pointer usage would normally >> be >> >dangerous around the garbage collector, but since I have a finalizer >> on >> >the "real" pointer and there is no way the code could access the >> >uintptr with the same value as the real pointer once the finalizer >> has >> >run or been removed by Close, shouldn't this code be safe? >> >> From the unsafe package's documentation: >> >> > Even if a uintptr holds the address of some object, the garbage >> > collector will not update that uintptr's value if the object moves >> >> One valid implementation strategy for a garbage collector is to do arena >> allocation, and on a GC pass copy all *live* objects out of an arena >> into another one for longer-lived objects, and then free the old arena. >> In this case, your uintptrs would still still contain the old addresses, >> even though the objects have moved. Note that the finalizer is never run >> in this case, because the object has been moved without being garbage. >> >> Whether what you're doing is actually safe depends heavily on the >> implementation details of the garbage collector. It may or may not >> be possible for it to break given the current implementation; >> I don't know enough about it to be sure. But a correct implementation >> of the runtime could very well corrupt memory given the code you >> linked; even if it works now, it's possible in a future release of >> Go this could break. >> >> Hope this helps, >> >> -Ian >> > > Is there any way to implement this safely, or should I just give up on the > weak pointer idea? > What will your *Session keep from getting collected if you have only weak pointers to it? Nothing. What are you trying to achieve? You have Session.Close. Why not have it clean up after itself - even from the session registry? Just have a "sessions=make(map[SessionID]*Session)", and do a "sessionsMtx.Lock(); delete(sessions, sess.id); sessionsMtx.Unlock()" in Session.Close. A WeakValueMap would eliminate the need of this explicit cleanup, but we don't have weak maps in Go. And Finalizers are totally unreliable - you don't know when will they be called, if called at all. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
Why do you want a weak pointer? What for? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: > > Quoting Ben Lubar (2018-09-29 14:40:28) > >[1]https://play.golang.org/p/iBAii-f84Sq > >vet is complaining because the unsafe.Pointer usage would normally be > >dangerous around the garbage collector, but since I have a finalizer > on > >the "real" pointer and there is no way the code could access the > >uintptr with the same value as the real pointer once the finalizer > has > >run or been removed by Close, shouldn't this code be safe? > > From the unsafe package's documentation: > > > Even if a uintptr holds the address of some object, the garbage > > collector will not update that uintptr's value if the object moves > > One valid implementation strategy for a garbage collector is to do arena > allocation, and on a GC pass copy all *live* objects out of an arena > into another one for longer-lived objects, and then free the old arena. > In this case, your uintptrs would still still contain the old addresses, > even though the objects have moved. Note that the finalizer is never run > in this case, because the object has been moved without being garbage. > > Whether what you're doing is actually safe depends heavily on the > implementation details of the garbage collector. It may or may not > be possible for it to break given the current implementation; > I don't know enough about it to be sure. But a correct implementation > of the runtime could very well corrupt memory given the code you > linked; even if it works now, it's possible in a future release of > Go this could break. > > Hope this helps, > > -Ian > Is there any way to implement this safely, or should I just give up on the weak pointer idea? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is this implementation of weak pointers safe?
Quoting Ben Lubar (2018-09-29 14:40:28) >[1]https://play.golang.org/p/iBAii-f84Sq >vet is complaining because the unsafe.Pointer usage would normally be >dangerous around the garbage collector, but since I have a finalizer on >the "real" pointer and there is no way the code could access the >uintptr with the same value as the real pointer once the finalizer has >run or been removed by Close, shouldn't this code be safe? >From the unsafe package's documentation: > Even if a uintptr holds the address of some object, the garbage > collector will not update that uintptr's value if the object moves One valid implementation strategy for a garbage collector is to do arena allocation, and on a GC pass copy all *live* objects out of an arena into another one for longer-lived objects, and then free the old arena. In this case, your uintptrs would still still contain the old addresses, even though the objects have moved. Note that the finalizer is never run in this case, because the object has been moved without being garbage. Whether what you're doing is actually safe depends heavily on the implementation details of the garbage collector. It may or may not be possible for it to break given the current implementation; I don't know enough about it to be sure. But a correct implementation of the runtime could very well corrupt memory given the code you linked; even if it works now, it's possible in a future release of Go this could break. Hope this helps, -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Is this implementation of weak pointers safe?
https://play.golang.org/p/iBAii-f84Sq vet is complaining because the unsafe.Pointer usage would normally be dangerous around the garbage collector, but since I have a finalizer on the "real" pointer and there is no way the code could access the uintptr with the same value as the real pointer once the finalizer has run or been removed by Close, shouldn't this code be safe? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
