[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