On Sat, 26 Jul 2003 16:53:59 +0200 (Romance Daylight Time) Vadim Zeitlin <[EMAIL PROTECTED]> wrote:
> On Sat, 26 Jul 2003 16:32:57 +0200 (CEST) Robert Vazan > <[EMAIL PROTECTED]> wrote: > > RV> IMO, there is a general problem with reentrancy that needs general > RV> solution. > > Yes, I totally agree. Unfortunately I also think that I know what this > general solution is: make Mahogany multithreaded. Actually I don't like threads either. :-) Threads are nice if you have well isolated area (like folder) where the thread can do background job. Once threads can interfere with each other, you need boatloads of locks. > In this particular > case I > am quite sure that MT-design will be much simpler than the current one. I don't understand how threads relate to modal dialogs. > RV> I've just stumbled into one problem in this class (I've got > RV> autosave in middle of composer construction) and I hotfixed it by > RV> carefully locking that part of code. > > Could you please send the patch? TIA! It will come as part of minimal composer. > This is not limited to modal dialogs. Calls to wxYield() (which are But who forces you to call wxYield? Dialogs are a must, but wxYield? > necessary for such mundae things as updating the cursor to show the busy > state under GTK) are very dangerous because of this. Yes, this is something that threads would be useful for. I have already found wxBusyCursor trap and we should ban this class once threads are in place. Meantime, idle loop can be used for background jobs. Yes, I know that c-client doesn't like it. > Under MSW the > virtual > list control can call us back at any time it needs to refresh. Why would it generate callback while dialog is open? Obviously user cannot scroll it and repeating old values invisibly inside wxListCtrl is just as good as calling application for this. If the dialog is consequence of scrolling (and happens in middle of refresh), you sure don't want to cause another refresh and another dialog. > There are > probably other things which I forget. However there are few thousands of asserts and up to few hundreds dialogs (some of them come from wxWindows itself) that are opened randomely without any locking. Event loop in these dialogs executes events that are mostly random too. So we get any event inside any event crash lotery. > No. You surely don't want to stop list control redrawing, without > speaking > of new mail checks, while a dialog is opened. This is not a solution. Dialog is usually opened for few seconds. There is no problem in delaying new mail checks and other timers. > I really don't think this is a good idea. Idle and other events should > be > continued to be generated while the dialog is shown. Processing in idle loop already caused several bugs as I remember. I bet it is used for other things than lenghty tasks. Why not execute shorter operations immediately? > Again, the real solution is to use threads. AFAICT, this doesn't solve reentrancy and when it is done in wrong way, it can make things much worse. Sort of any instruction after any instruction instead of any event inside any event. Theoretically, it can be all solved with sufficient locking, but we don't have this locking and we will never get it. ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
