Re: Desktop::Editor again

>>>>> "Martijn" == Martijn van Beers <> writes:

Martijn> New version after comments. There's one problem with this
Martijn> one, but I'm not sure how to fix that. Several processes can
Martijn> get the same EditorView object. This means the cursor
Martijn> position/selection could change between calls from one
Martijn> component. I'm really no locking expert, so please give me
Martijn> some hints :)

My advice is to try hard to design interfaces that don't need
locking.  That lets you avoid a whole class of bugs.

I'd say in this case just document that clients can't rely on these
things not changing.  Is that a big problem?  What are the results of
a "failure"?  Not too bad: the user sees something that program B
thinks is relevant instead of what program B thinks is relevant.

What if the user herself changes the selection?  Or will the user be
prevented from using the mouse and scrollbar of the editor while some
client has the lock?

The problem with locking is that if the client dies then you are


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]