The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

calling all [c++] architechture gurus

gonna pull on the wise developers here at jos :)

Suppose that I have a UI control which handles key presses and such, one of which is used to execute an app "command".
Unfortunately, the app has sessions, which on a new session, removes all previous UI elements and creates them again (with new data).  The problem is that this control which is handling the key presses is deleted *while* the command is still executing! 

In this case, what would be the best way to approach to address this issue? an architechture rewrite is no possible ... any tricks I can use?
cheetah Send private email
Monday, March 20, 2006
 
 
Sorry cheetah, there's not enough detail.

In general though you can't delete something while it's being used. Some ways around that are make a copy, reference counting, patch it so it doesn't delete and do the delete later, queue the work to another thread and get a notification when the work is done.
son of parnas
Monday, March 20, 2006
 
 
As previous poster said, not much info, but here goes anyway:

I think what you need is some kind of asynchronous message passing ("fire and forget"). 

For instance, if we assume Win32, SendMessage is synchronous -- it sends a message to a window via a direct call, and so the sender really can't delete himself in the scope of the call (or bad things are likely to happen).

By contrast, PostMessage simply puts a message in the window's msg queue, and returns immediately.  At that point, there should be no problem if the sending control gets deleted.  (To be certain, write a little code to test it!)

Similar mechanisms exist in other UI toolkits (e.g., XWindows).
BillT Send private email
Monday, March 20, 2006
 
 
Could the control lock a mutex? Not much info, like others have stated, but it sounds like a concurrent access problem.
A. Nonymous
Monday, March 20, 2006
 
 
Good idea on the mutex, but it would have to be located in a shared context that wasn't being deleted.
son of parnas
Monday, March 20, 2006
 
 
I was hoping for a platform independent was of getting around this, but thanks for the tips.  I'm not sure that I can use PostMessage as it is hard to tell when I need to clean up like this and when not to.

The command works as if i had a string "newFile" which is parsed and executed.  Before executing the command, I have no idea what it will do, and many different commands may have this affect, on various controls.  I'm pretty sure it's not a synchronization issue also, because if the UI control held the mutex, then the execution of the command would not complete (waiting for UI to release lock) and the UI function would not complete (waiting for execution to complete)?
Cheetah
Monday, March 20, 2006
 
 
It sounds to me like you need to do some sort of (1) reference counting or an (2) additional level of indirection.
1) When you start an asynchronous job, you hand it a reference to the elements is could update, and increment a reference count.  The elements are only destroyed when the reference count goes to 0 (so on completion, the job may be updating elements that are no longer visible).
2) You would set up some table of pointers to elements that you would pass to the job.  When the job completes, it doesn't reference the elements directly, but rather looks in its table.  You can wipe the table when you clear the UI (because it sounds like you don't want to update the new UI).

Or easiest, you just check if you are in the same session when the job completes.  It could be just some global variable that gets incremented for each session change.  The job makes sure that the session hasn't changed before it tries updating the UI.

Add synchronization where appropriate.
bmm6o Send private email
Monday, March 20, 2006
 
 
PostMessage, don't get fancy.
onanon
Monday, March 20, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz