Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!satisfied.elf.com!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.mtholyoke.edu!world!edwards
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: breakpoints
Message-ID: <D47Gp4.Bqz@world.std.com>
Keywords: breakpoint halt
Organization: IntraNet, Inc.
References: <3i0323$lnk@mozo.cc.purdue.edu>
Date: Sat, 18 Feb 1995 17:03:04 GMT
Lines: 25

In article <3i0323$lnk@mozo.cc.purdue.edu>,
Rajesh Piplani <piplani@rainbow.ecn.purdue.edu> wrote:

>I also feel that there has to be a better way of setting
>breakpoints than to use self halt. My problem is even worse
>since I use smalltalk for simulation, and would like to be able
>to halt the program and than advance it. But since in simulation
>(as I am sure in other applications) you have multiple threads
>running, if you halt one thread, other threads keep running, and
>you can't continue the program from thereon. The only way is to
>restart the program all over again.

QKS seems to have a thread-aware debugger. Haven't looked into it in detail.
In the C/C++ world, multithreaded debuggers allow you to freeze all threads
whenever the debugger is activated. You can browse among all running threads,
and set breakpoints that are thread-specific.
My modern standards, Smalltalk has a primitive debugger.




-- 
Jonathan Edwards				edwards@intranet.com
IntraNet, Inc					617-527-7020
One Gateway Center				FAX: 617-527-6779
