[ros-kernel] Commits to subsys/win32k
Joakim Asplund
joakim_asplund at spray.se
Fri Aug 6 15:05:59 CEST 2004
Thomas Weidenmueller wrote:
>
>> At first glance it seems this approach,
>> paired with the unock/callback/lock idiom can create a few problems -
>> what
>> if a thread on CPU0 is doing unluck(butterfingers, but I left it
>> misspelled
>> since it became quite appropriate) in preparation to do a callback,
>> but then
>> CPU1 gets the global lock and e.g. closes the window?
>>
>>
> I already considered this case. Therefore the object is referenced
> before releasing the lock. When it gets destroyed it's still in memory
> so we don't get into trouble when returning from the callback. After
> the callback the lock is acquired again and it is checked if the
> window and/or thread was destroyed. If so, further code needs special
> handling of course. But that's not solved well in our current
> implementation as well.
>
>
A window can actually only be destroyed by the thread that created it so
the only thing to watch out for is if DestroyWindow is called inside the
callback.
--
Joakim Asplund
More information about the Ros-kernel
mailing list