On Sat, 26 Jul 2003 20:01:13 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
RV> Actually I don't like threads either. :-) Me neither and I always say that people use them too much and when this is really uncalled for. However I think in this case they are the best solution. RV> I don't understand how threads relate to modal dialogs. But modal dialogs are not the real problem... The problem is that we try to do things "asynchronously" using a single thread and this is very complicated and doesn't really work. RV> > This is not limited to modal dialogs. Calls to wxYield() (which are RV> RV> But who forces you to call wxYield? Dialogs are a must, but wxYield? If you want to show progress dialogs you must use it. RV> > necessary for such mundae things as updating the cursor to show the busy RV> > state under GTK) are very dangerous because of this. RV> RV> Yes, this is something that threads would be useful for. I have already RV> found wxBusyCursor trap and we should ban this class once threads are in RV> place. Meantime, idle loop can be used for background jobs. Yes, I know RV> that c-client doesn't like it. We do use the idle loop for background jobs. All M events are dispatched from wxWindows idle handler. RV> > Under MSW the virtual list control can call us back at any time it RV> > needs to refresh. RV> RV> Why would it generate callback while dialog is open? It is enough to move dialog over it (thus invalidating a part of it and requiring it to repaint itself). RV> > There are probably other things which I forget. RV> RV> However there are few thousands of asserts and up to few hundreds RV> dialogs (some of them come from wxWindows itself) that are opened RV> randomely without any locking. Event loop in these dialogs executes RV> events that are mostly random too. So we get any event inside any event RV> crash lotery. You don't need to do locking when showing the dialog. You must protect the critical code sections against reentrancies. It's still not an easy task, of course... RV> > No. You surely don't want to stop list control redrawing, without RV> > speaking of new mail checks, while a dialog is opened. This is not a RV> > solution. RV> RV> Dialog is usually opened for few seconds. _I_ have already spent many minutes in the options dialog. I expect that an average user won't be quicker than me. Ok, so it's an argument for the redesign of the options dialog, but still, this is wrong. You can spend half an hour writing filters in the filters dialog, for instance. RV> Processing in idle loop already caused several bugs as I remember. I bet RV> it is used for other things than lenghty tasks. Why not execute shorter RV> operations immediately? Because c-client can't be reentered so we *must* queue any requests to it. Not doing it results in immediate abort(). RV> > Again, the real solution is to use threads. RV> RV> AFAICT, this doesn't solve reentrancy and when it is done in wrong way, RV> it can make things much worse. Yes. But we need MT anyhow to allow the user to interrupt lengthy operations (just try retrieving the list of all newsgroups from your NNTP server now... ok, no, don't try it as you probably don't wait to wait for half an hour) and to do several things in parallel. And if done correctly it will solve the reentrancy problems as well. Regards, VZ ------------------------------------------------------- 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
