Alaska Software Inc. - not switching between threads

	Author	Topic: not switching between threads
	Doug Schwerin	not switching between threads on Sat, 22 Mar 2008 21:10:57 -0600 In one application I have done. There is a thread in which you can page through customer files. During this process the application will periodically go back to thread one for a few passes, then return to thread three to continue with customer records. It seems that since I upgraded to 1.9 that for some reason the application will switch to thread one and then never go back to three. I have four applications that follow a similar pattern of operation. Only this one seems to get lost during thread switching. Any ideas?? Doug
	AUGE_OHR	Re: not switching between threads on Sat, 10 May 2008 19:53:17 +0200 hi, > During this process the application will periodically go back > to thread one for a few passes, then return to thread > three to continue with customer records. how to you "switch" Threads ? (show us some code) are you :Quit Thread 3 before return to Thread 1 > It seems that since I upgraded to 1.9 that for some reason the > application will switch to thread one and then never go back > to three. what type of Memvar you are using to :create your Thread():New() ? will your RAM increase when "switching" between Thread 3-1-3 ? > Any ideas?? show us a sample and some code else nobody can help you with "your" code ... nevertheless, we are no clairvoyant. greetings by OHR Jimmy
	Doug Schwerin	Re: not switching between threads on Wed, 14 May 2008 02:21:37 -0600 On Sat, 10 May 2008 19:53:17 +0200, AUGE_OHR wrote: > hi, > >> During this process the application will periodically go back >> to thread one for a few passes, then return to thread >> three to continue with customer records. > > how to you "switch" Threads ? (show us some code) > are you :Quit Thread 3 before return to Thread 1 > >> It seems that since I upgraded to 1.9 that for some reason the >> application will switch to thread one and then never go back >> to three. > > what type of Memvar you are using to :create your Thread():New() ? > will your RAM increase when "switching" between Thread 3-1-3 ? > >> Any ideas?? > > show us a sample and some code else nobody can help you > with "your" code ... nevertheless, we are no clairvoyant. > > greetings by OHR > Jimmy "how to you "switch" Threads ?" According to the documentation, the operating system handles the switching between threads, so I am not influencing the switching process. "what type of Memvar you are using to :create your Thread():New() ?" PROCEDURE MyMenuProcedure( nMenuSelection ) private oThread := Thread():New() DO CASE CASE nMenuSelection == 101 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "Customer" ) CASE nMenuSelection == 102 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "Routes" ) CASE nMenuSelection == 103 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "Groups" ) CASE nMenuSelection == 104 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "RentalItems" ) CASE nMenuSelection == 105 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "SngleInvoice" ) CASE nMenuSelection == 106 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "FileMaint" ) CASE nMenuSelection == 107 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "DataPath" ) CASE nMenuSelection == 108 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "CmpanyInfo" ) CASE nMenuSelection == 109 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "PrntRute" ) CASE nMenuSelection == 110 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "PrntInvce" ) CASE nMenuSelection == 111 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "RcrdPurge" ) CASE nMenuSelection == 112 ProgramEnd() CASE nMenuSelection == 201 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "ChngsCstomrs" ) CASE nMenuSelection == 202 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "ChngsRntals" ) CASE nMenuSelection == 203 If WindowCount = 0 oStatic09:destroy() PictureOn = .F. Endif WindowCount = WindowCount + 1 oThread:Start( "Contracts" ) ENDCASE oThread:Start( "Customer" ) This is the module that when started runs as thread 3 in version 1.9 and thread 2 when the same code is compiled and ran using version 1.7 The remainder of the program is comprised of the following RENTAL.PRG 422 CmpanyInfo.prg 1098 Customer.prg 903 Routes.prg 3388 Groups.prg 720 RentalItems.prg 925 Datapath.prg 92 SngleInvoice.prg 2023 FileMaint.prg 564 PrntRute.prg 817 PrntInvce.prg 2996 ChngsCstomrs.prg 2588 Procedure.prg 6671 ChngsRntals.prg 876 Contracts.prg 472 RcrdPurge.prg 1031 Total lines 25586 as well as 76 Mbytes of data in about 92 dbf and ntx files This program was originally a clipper aplication that has evolved over about 20 years.It is still growing as I add other functions to it. Here is my last contact with tech support: Hi Doug, Thank you for the very descripting explenation of what you are seeing at your side. I have tried to reproduce the pattern you are describing and tried to debug my sample according your instructions - I might have missed the point somewhere. So it would be required to work with your code, however this is not possible for me as long your account is frozen at our side. Please get in contact with info@alaska-software.com for getting information about how to optain entitlement for getting Alaska Software support services. With best regards, Andreas Herdt Alaska Technical Support -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm Fax European Office: +49 (0) 61 96 - 77 99 99 23 Fax US Office: +1 (646) 218 1281 -------------------------------------------------------------------- ----- Original Message ----- From: "Doug Schwerin2" <d.schwerin_ncomp@sasktel.net> To: "Alaska Technical Support" <support@alaska-software.com> Cc: <info@alaska-software.com> Sent: Thursday, March 27, 2008 8:06 AM Subject: Re: Won't return to thread > Andreas > I am sending you a text doc that I hope will give you the information needed to understand what is happening. I have also sent a > post to the Xbase++ Bugreport group. I have contacted you because there is no error code generated by this situation. I am at a > loss as to where to look to correct the situation. I have at least three other programs that more or less follow the same > programming style and are working ok. In addition the original version of the program is working ok compiled with version 1.7 > Doug Schwerin > > > ----- Original Message ----- > From: Alaska Technical Support <support@alaska-software.com> > Date: Wednesday, March 26, 2008 9:55 am > Subject: Re: Won't return to thread > >> Hallo Mr Schwerin, >> >> Thank you for contacting us. >> >> From the description you have provided so far, It is not clear to >> me to >> the last extend what the pattern is at your side. So let me recap >> what I >> have understood. >> >> In your multithreaded application a dialog is displayed using a >> dedicatedthread (thread 3). You have the impression that from a >> certain point of time >> one thread is is no longer scheduled. >> >> Additionally, I have understood that using the debugger, some code >> is no >> longer processed in a thread. >> >> First of all, please let me state that this clearly is not related >> to the size of >> the application. In Windows 32 Bit environment restrictions or >> shortcomingsdo not exist that arise from the size of the executable. >> >> What is not clear to me is whether you have implemented some mechanism >> where you gain control about thread switches. This would be the >> case if you >> are using the Signal class for example. >> >> This that, I feel that it is required to come again and give a >> brief and exact >> description about the pattern you are using. What code is >> implemented and >> where are the dependencies between these threads. Furthermore, please >> describe how you come to the impression that a thread does not >> return in >> a life application that you have deployed at a customer of yours. >> >> Beside of this, I have realized that your free support is expired. >> According my >> records you have purchased Xbase++ 1.9 on June, 22nd 2006. Free >> technicalsupport is limited to a timeframe of 1 year. To clearify >> your status and for >> information how to proceed, please get in contact with info@alaska- >> software.comwith your CID A082266. >> >> With best regards, >> Andreas Herdt >> Alaska Technical Support >> >> ------------------------------------------------------------------- >> - >> Technical Support: support@alaska-software.com >> >> News Server: news.alaska-software.com >> Homepage: http://www.alaska-software.com >> WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm >> >> Fax European Office: +49 (0) 61 96 - 77 99 99 23 >> Fax US Office: +1 (646) 218 1281 >> ------------------------------------------------------------------- >> - >> >> ----- Original Message ----- >> From: "Doug Schwerin2" <d.schwerin_ncomp@sasktel.net> >> To: "Alaska Software Support" <support@alaska-software.com> >> Sent: Tuesday, March 25, 2008 4:18 AM >> Subject: Won't return to thread >> >> >> > Alaska Software CID:A082266 >> > >> > I have three or four applications that follow similar design in >> the programming. One is a fair bit larger than the other two and >> > has developed a problem with the thread processing. It starts >> out with thread one as the main routine. When a customer >> information >> > page is called this comes up as thread three. I don't know what >> happened to thread two, but that doesn't seem to be an issue. >> > While the program is processing information, stepping through >> customer files, in thread three, it will periodically go back to >> > thread one and make a few passes through its event loop. In any >> where from 3 or 4 to as many as 21 or 22 steps through customer >> > information, it will keep going back to thread one periodically. >> Then for some reason it will not go back to thread 3, it simply >> > stays in thread one. Both threads are shown in the dbug window, >> but no way will it return to thread 3. I have a feeling it may >> > have something to do with the size of the program. >> > >> > I am using Alaska ver 1.9, this computer is running Windows 2000 >> pro service pack 4 It has 2,096,236 Kb RAM running an Intel Core >> > 2 Duo CPU at 2.20 Ghz. The same problem occurs on a second >> machine on the network that is running WIN XP Pro Version 2002 >> service >> > pack 2 It also is running a Core 2 Duo CPU at 2.00 Ghz and has >> 0.99 Gbytes of Ram. When this problem first started it was more >> > apparent on the XP machine and in fact didn't seem to be >> apparent on the Win2K machine at all or occured very seldomly. >> > >> > I have an earlier version of the program running on a Win 2K >> machine at a customer's site. It does not display any of this >> > behavior, but was compiled using v1.7 and is slightly smaller as >> some additional modules have been added to the newer version, but >> > some changes to procedures have shortened the program perhaps as >> much as the addition of the new module has increased the code >> > size. >> > >> > I would like to get this problem cured as the customer is >> looking forward to some of the enhancements to the new version If you want more information, please tell me what you require? Doug Alaska Tech Support.txt
	Andreas Gehrs-Pahl	Re: not switching between threads on Wed, 14 May 2008 07:33:00 -0400 Doug, First, never, ever, post your Alaska Customer ID publicly! I suggest you contact Alaska and asked them to assign you a new one and retire the old one! Second, about your problem -- it seems that you are describing the behavior of the Xbase++ 1.9 XppDbg.exe debugger, which is slightly different to that of previous versions. Based on your posts, there seems to be ONLY a problem while you (try to) debug your program, but not if you run it (without the debugger) by itself. If this is not the case -- and you do have problems outside the debugger -- please describe the behavior that you see in the production program in more details. If the problem is only with the debugger, than I suppose the following might help you with debugging your program. As you noticed, in Xbase 1.90 there will always be a (hidden/terminated) thread number "2" created. I assume that this thread is created at start-up by the runtime and is immediately terminated, so the first thread created by your program will always have thread number 3. A new behavior of the debugger is that, when stepping through the code with F8 (and also sometimes with F10 and F4), the program execution might be quite slow, especially if you monitor a lot of variables. Additionally, the debugger might choose to only step through code that is executed in a particular thread (after some time, when using F8), which seems to be your (described) problem. This is the same effect as you get by "un-focusing" and/or "disabling" the other threads, even though the threads are not shown as having "NOFOCUS" or as being "DISABLED" in the debugger. The best way to debug a specific thread and prevent the above problem -- specifically if you are not interested in the occasional event loop execution of your (main) thread (1) but only in the code in thread 3 -- is to change the other thread's focus settings. If you remove focus from thread 1, only code running in thread 3 is debugged or stepped-through, unless you set a break point in the other thread's code or interrupt the program flow otherwise in that thread with AltD() or pressing CTRL-S, etc. To set (or remove) focus to a thread, just select (highlight) it in the "Commands" --> "List Threads" dialog and press "n". The thread will be listed as "NOFOCUS" in the last column. If you want to debug the thread again, just select it in the list and press "f". Having only one thread with "FOCUS" will also speed up F8 (Step) and F4 (Step Back) executions! I don't know the exact reason for those changes in Version 1.90, but one effect is that the debugger will now handle much more variables than it could handle in previous versions. On the other hand, it seems much slower and quite often crashes with IDSCs and similar errors -- especially if you monitor field variables, any database operation might result in an IDSC! One other option would be to switch to VX 2.0 and use the integrated Visual Xbase++ debugger, and see if that one works better for you. -- Andreas --- --- Andreas Gehrs-Pahl E-Mail: GPahl@CharterMI.net 415 Gute Street or: Andreas@DDPSoftware.com Owosso, MI 48867-4410 or: Andreas@Aerospace-History.net Tel: (989) 723-9927 Web Site: http://www.Aerospace-History.net --- ---
	Doug Schwerin	Re: not switching between threads on Thu, 15 May 2008 00:47:14 -0600 On Wed, 14 May 2008 07:33:00 -0400, Andreas Gehrs-Pahl wrote: > Doug, > > First, never, ever, post your Alaska Customer ID publicly! I suggest you > contact Alaska and asked them to assign you a new one and retire the old > one! > > Second, about your problem -- it seems that you are describing the behavior > of the Xbase++ 1.9 XppDbg.exe debugger, which is slightly different to that > of previous versions. Based on your posts, there seems to be ONLY a problem > while you (try to) debug your program, but not if you run it (without the > debugger) by itself. If this is not the case -- and you do have problems > outside the debugger -- please describe the behavior that you see in the > production program in more details. > > If the problem is only with the debugger, than I suppose the following might > help you with debugging your program. As you noticed, in Xbase 1.90 there > will always be a (hidden/terminated) thread number "2" created. I assume > that this thread is created at start-up by the runtime and is immediately > terminated, so the first thread created by your program will always have > thread number 3. A new behavior of the debugger is that, when stepping > through the code with F8 (and also sometimes with F10 and F4), the program > execution might be quite slow, especially if you monitor a lot of variables. > Additionally, the debugger might choose to only step through code that is > executed in a particular thread (after some time, when using F8), which > seems to be your (described) problem. This is the same effect as you get by > "un-focusing" and/or "disabling" the other threads, even though the threads > are not shown as having "NOFOCUS" or as being "DISABLED" in the debugger. > > The best way to debug a specific thread and prevent the above problem -- > specifically if you are not interested in the occasional event loop > execution of your (main) thread (1) but only in the code in thread 3 -- > is to change the other thread's focus settings. If you remove focus from > thread 1, only code running in thread 3 is debugged or stepped-through, > unless you set a break point in the other thread's code or interrupt the > program flow otherwise in that thread with AltD() or pressing CTRL-S, etc. > To set (or remove) focus to a thread, just select (highlight) it in the > "Commands" --> "List Threads" dialog and press "n". The thread will be > listed as "NOFOCUS" in the last column. If you want to debug the thread > again, just select it in the list and press "f". Having only one thread > with "FOCUS" will also speed up F8 (Step) and F4 (Step Back) executions! > > I don't know the exact reason for those changes in Version 1.90, but one > effect is that the debugger will now handle much more variables than it > could handle in previous versions. On the other hand, it seems much slower > and quite often crashes with IDSCs and similar errors -- especially if you > monitor field variables, any database operation might result in an IDSC! > > One other option would be to switch to VX 2.0 and use the integrated Visual > Xbase++ debugger, and see if that one works better for you. > > -- Andreas > > --- --- > Andreas Gehrs-Pahl E-Mail: GPahl@CharterMI.net > 415 Gute Street or: Andreas@DDPSoftware.com > Owosso, MI 48867-4410 or: Andreas@Aerospace-History.net > Tel: (989) 723-9927 Web Site: http://www.Aerospace-History.net > --- --- The situation occurs when the program is running with or without dbug. I have noticed when using dbug to monitor activity that the switch to thread 1 usually occurs when a file is about to be read. This may not always be the case, but it seems that way. At this point in the program, the last customer's information has been deleted from the screen and we are about to open data bases to get the next customer's information. The thread switches to 1 and stays there, so all you see is a blank screen. You can exit the program by selecting the menu exit, or by closing the window, upper right hand x on the window frame. When this problem first started to occur it seemed that it would happen on the win XP pro machine on occasion, and the win 2K machine when the program was running under dbug. It seemed that as the program grew it occured more frequently until you can only move any where from 2 or 3 to 10 or 15 customer records before the switch back to 3 does not occur. I have three programs at work that are still running under 1.9 So far this situation has not occured in them that I have noticed until the other day the smallest of them exhibited the same type of behavior, so perhaps program size is not a factor. I have also monitored memory and cpu usage and there doesn't seem to be any problem there that I can see. I have continued to make changes to the program using v 1.7, but I would like to go back to using v 1.9 I think your idea about stopping thread one may have some merrit. I may load up ver 1.9 and try that approach.
	Andreas Gehrs-Pahl	Re: not switching between threads on Thu, 15 May 2008 06:56:41 -0400 Doug, >The situation occurs when the program is running with or without dbug. >I have noticed when using dbug to monitor activity that the switch to >thread 1 usually occurs when a file is about to be read. Are you sure that Thread 3 is still running at that time? It looks to me more like an error occurred in that thread or it has terminated for some other reason. Have you checked for XppFatal or XppError log files in the "current" directory? Do you use the default Error Handler or a customized one? Could it be that the thread ran into an IDSC and was terminated, while your main thread's event loop is still running along as if nothing happened? I would check for that possibility first! For debugging purposes, I use a routine that shows me the status of all user threads in an XbpQuickBrowse table, displaying Thread Number, ID, Handle, the current Call Stack and other information, which is refreshed every five seconds or so. Maybe you want to add something like this to your program as well. It might tell you what is going on in your code. I have included a couple of screen shots of such Thread List dialogs. Another possibility is to include the Xbase++ Profiler, which will allow you to analyze the program flow between multiple threads, besides other things. This should show you the last statement that was executed in the "lost" thread, just before it happened. -- Andreas --- --- Andreas Gehrs-Pahl E-Mail: GPahl@CharterMI.net 415 Gute Street or: Andreas@DDPSoftware.com Owosso, MI 48867-4410 or: Andreas@Aerospace-History.net Tel: (989) 723-9927 Web Site: http://www.Aerospace-History.net --- --- ThreadL1.png ThreadL2.png