Deform brush and deadlocks

[C. Boemann]

[15:55] <boemann> boud: you know, if we make write access exclusive we 
also prevent two write iterators on say different lines from working
[15:56] <boemann> as access is per tile and not per pixel
[15:56] <-- fyanardi has left this server (Read error: 54 (Connection reset by 
peer)).
[15:56] <boemann> that might break some algorithms
[15:56] <boud> yes, indeed
[15:57] <boemann> on the other hand two tiles accessing the same tiles 
shouldn't be allowed from a more top down perspective
[15:57] <boud> better put that in a mail so dmitry sees it too
[15:57] <boemann> i've told him before
[15:57] --> fyanardi has joined this channel (n=edi at 116.197.231.178).
[15:58] <boud> not sure what you mwith two tiles accessing the same tiles
[15:58] <boemann> two iterators
[15:58] <-- slangkamp has left this server ("Konversation terminated!").
[15:58] <boemann> now threads
[15:58] <boemann> sorry
[15:58] <boemann> on the other hand two threads accessing the same tiles 
shouldn't be allowed from a more top down perspective
[15:59] <boud> yes
[15:59] <boud> so two iterators in the same thread shouldn't be a problem
[15:59] <boemann> i think that must be up to the algorithm writer
[16:00] <boemann> but the example of drying filer  together with user 
painting is a problem because there it isn't easy to tell the user not to draw
[16:01] <boemann> on the other hand we don't want the drying filter to lock 
everything
[16:01] <-- burmas has left this channel ("Konversation terminated!").
[16:02] <boemann> so for cases where multiple operations are taking place 
at the same time we do need some kind of locking
[16:02] <boemann> but we don't need it for cases where a single task is 
divided between threads
[16:03] <boemann> and right now the only multiple operation usecase i can 
come up with is drying+user painting
[16:04] <boud> yes... recomposition only needs read access and can wait 
until the user is done painting on a tile.
[16:04] <boemann> yes
[16:05] <boemann> i think that maybe if we in the future needs multiple 
operation locking we should then come up with another api
[16:05] <boemann> something on top of the timemanager
[16:05] <boemann> tile
[16:06] <boemann> like a way to say: hey i'm locking this qrect for a while
[16:06] <boud> yes
[16:06] <boud> although that is more or less what you get when you lock a 
tile :-)
[16:07] <boemann> true but we have just established that we can't in 
general lock tiles
[16:07] <boemann> besides locking tiles adds overhead for no good reason 
in general
[16:08] <boemann> only trouble with a new api is that current tools don't 
know about it and would probably need to be modified
[16:08] <boemann> for that reason doing it in the tilemanager would be nice
[16:09] <boud> besides, we don't want to bother filter or paintop writers with 
explicit locking or unlocking
[16:09] <boemann> right
[16:09] <boemann> idea:
[16:10] <boemann> what if we provide a method: 
paintdev::setLockOtherUsers(bool)
[16:11] <boemann> that would signal the taskmanager that tile access by 
this thread is exclusive
[16:11] <boemann> other users of the paintdev would be locked out of the 
tile whenever the exclluve tile has a lock on it
[16:11] <boemann> but in general tiles are not locked
[16:12] <boemann> this exclusiveness can then be used by drying filter like 
stuff
[16:12] <boud> I'm not sure I like that idea
[16:12] <boemann> why
[16:13] <boud> well, I might not get it, but I think it's too explicit
[16:13] --> DetroitLibertyPe has joined this channel 
(n=Parrot_T at 209-255-22-2.ip.mcleodusa.net).
[16:13] <boud> and we would have to mutex around the getter for that paint 
device
[16:13] <-- DetroitLibertyPe has left this channel.
[16:13] <boud> I'm not sure I've got the real requirements clear, though
[16:13] <boemann> we would have to do that with any locking mechanism