Page 2 of 2

Re: 0.9.11 plan

Posted: Sat Oct 29, 2016 5:02 pm
by Glocke
Yes, the unique_ptr would delete the event as the unique_ptr's scope is left.

The initial problem was, that the Win32-API returns an owning-pointer and the X11-API a non owning-pointer, right?. Is there a reason to let the Window API hold the event any further (X11 case)?

Re: 0.9.11 plan

Posted: Sat Oct 29, 2016 5:06 pm
by deva
The underlying APIs are vastly different so this was the most intuitive way to make it.
I think we should do a more thorough redesign when we start implementing the MacOSX backend and leave it with shared_ptr for now?

Re: 0.9.11 plan

Posted: Sat Oct 29, 2016 5:20 pm
by Glocke
deva wrote:The underlying APIs are vastly different so this was the most intuitive way to make it.
I think we should do a more thorough redesign when we start implementing the MacOSX backend and leave it with shared_ptr for now?
Well, so we should redesign that to have some common API. But: Using a shared_ptr cannot solve this problem!

Because the API returns a pointer to the first element of a vector, the resource is still owned by the API instance. Furthermore, the last shared_ptr - that goes of out scope - deletes the resource. Hence, your shared_ptr instance cannot know whether it's the last shared_ptr instance holding this resource. It does not even know whether you called the X11 or Win32 API (the code is using polymorphism if I understood it correctly).

So we have the following cases:
1. The X11 API is called, which returns an owning resource. The shared_ptr releases it correctly (as a unique_ptr would do, too). Everthing's fine
2. The Win32 API is called, which returns a non-owning resource. The shared_ptr also releases it (like a unique_ptr would do xD) because from it's point of view, it's the last shared_ptr holding this resource. The Win32 API might crash when trying to double free the resource.

Feel free to question this :)

Hence, we have to redesign the API-handling asap (imho). So the initial question is about return pointer or object. If we return a pointer, we should use unique_ptr. Idk the exact size of the event, but if it's small, I'd return the actual object (no ptr, no reference). So we copy it on return. The Win32 API can still hold its internal stuff, and the call for X11 will delete the owning-ptr after copying the resource.

Re: 0.9.11 plan

Posted: Sat Oct 29, 2016 6:15 pm
by deva
The win32 Events are stored as shared_ptr inside the vector so I think it should work as intended.

Returning a copy of the object will destroy the polymorphic type so that won't work out-of-the-box. But something like that would definitely be nice.
Perhaps a single event type with a union inside?

Re: 0.9.11 plan

Posted: Sun Oct 30, 2016 9:23 am
by Glocke
deva wrote:The win32 Events are stored as shared_ptr inside the vector
Really :shock: ... wtf
deva wrote:Returning a copy of the object will destroy the polymorphic type so that won't work out-of-the-box. But something like that would definitely be nice.
Perhaps a single event type with a union inside?
The event is polymorphic, too? Omg, we should wrap this entire mess and provide a common event that we can handle easily.