From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9cb6352457d1c6de X-Google-Attributes: gid103376,public From: mfeldman@seas.gwu.edu (Michael Feldman) Subject: Re: is there a 'wait' command in Ada Date: 1996/12/03 Message-ID: <583052$1tg@felix.seas.gwu.edu>#1/1 X-Deja-AN: 202232451 references: <1996Dec3.072025.1@eisner> organization: George Washington University newsgroups: comp.lang.ada Date: 1996-12-03T00:00:00+00:00 List-Id: In article <1996Dec3.072025.1@eisner>, Larry Kilgallen wrote: >If the debugger in question cannot deal with threads, that still >seems to me to be a debugger issue. I thought I read from Mike's >comment that a correct program would run alright unless the >debugger is introduced. Yes, that's true. So what? How should one debug a program that uses a simple delay? A program that behaves funny under the debugger behaves funny. Recall that I answered the original question by saying "the behavior may be surprising." I stand by that statement.:-) Actually, I've been messing with GDB on Solaris to see if there's a workaround. It turns out that SIGWAITING is raised, apparently, whenever a delay or whatever is encountered in the program. On Solaris at least, typing, at the gdb command prompt, handle SIGWAITING nostop handle SIGWAITING noprint seems to work. I haven't tried this (yet) on other platforms. In any event, this is not the least bit obvious to a non-GDB expert. Mike Feldman