CudaArray doesn't have a finalizer, CudaPitchedArray does

[ikirill]

I was looking at how long a pointer generated with CudaArray is guaranteed to stay alive for, and I noticed that CudaArray doesn't call finalizer(..., free) on itself in its constructor, so it looks like its pointer will be alive until the array gets freed explicitly, while CudaPitchedArray has a very different behaviour, and losing a reference to a CudaPitchedArray seems to deallocate the underlying pointer.

• https://github.com/JuliaGPU/CUDArt.jl/blob/master/src/arrays.jl#L100
• https://github.com/JuliaGPU/CUDArt.jl/blob/master/src/arrays.jl#L183

Is there a reason for implementing such different behaviours? It doesn't get described in the README, and I think it would be less confusing to have the two array types behave similarly (one way or the other). I don't know what was intended there, but I was expecting CudaArray to be finalized as well.

Another confusing thing is that malloc adds its own finalizer (https://github.com/JuliaGPU/CUDArt.jl/blob/master/src/pointer.jl#L38), but if the reference to a CudaPitchedArray gets lost, doesn't the pointer get freed regardless of whether there are still references to the pointer itself?

I'm not really saying any of this is strictly wrong, just that the rules governing malloc, free, and finalizers should be as clear as possible.

[timholy]

I think they are the same in practice: if you lose a reference to a CudaArray, it can be gc()ed; since that eliminates the reference to the pointer, it too can be gc()ed and that causes the memory to be freed. It's just a little more direct with a CudaPitchedArray.

However, I agree it's a little confusing to have these behave differently. Feel free to clean it up and submit a PR.

[ikirill]

Can't I keep a pointer myself, while dropping a reference to the array? If the pointer gets freed anyway, that's a problem.

I think only the pointers (wrappers around Ptr{Void}), coming from malloc* should have finalizers, that way there's no problem with mysterious clean up mechanics.

[timholy]

That would be reasonable.