Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!decwrl!sgi!shinobu!odin!bananapc.wpd.sgi.com!ciemo
From: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz)
Newsgroups: comp.sys.sgi
Subject: Re: What does winopen(3G) do?
Keywords: winopen sgi edge background parent child wsh
Message-ID: <8275@odin.corp.sgi.com>
Date: 30 May 90 22:58:33 GMT
References: <May.29.20.11.19.1990.700@genesis.rutgers.edu>
Sender: news@odin.corp.sgi.com
Reply-To: ciemo@bananapc.wpd.sgi.com (Dave Ciemiewicz)
Distribution: na
Organization: Silicon Graphics, Inc.
Lines: 57

In article <May.29.20.11.19.1990.700@genesis.rutgers.edu>,
broderic@genesis.rutgers.edu (Alfred J. Broderick) writes:
> 
> It seems that all programs that use winopen(3G) (including `wsh`)
> run in the background but do not show up in the when you type `jobs`.  
> How does this work?  Is there any way to debug programs that use
> winopen with `edge`?  Whenever I try to use `edge` to debug a program
> that uses winopen, my program runs to completion before edge is able
> to do a "stop at".
> 
> Any help and explainations will be appreciated.
> 
> Alfred Broderick
> broderic@topaz.rutgers.edu
> -- 
> Alfred++

winopen() forks a copy of the program in such a way that program is
backgrounded.  By default, dbx/edge do not stop on the fork system
call.

Solution 1
----------
There is a mode in dbx/edge to force this adding the forked
child process to your process pool,

	set $promptonfork=2

You can then click on the newly created child process in the edge
window and hit debug to select the child process for debugging.

Solution 2
----------
Another approach is to force a GL program.  To do this, use the
foreground(3G) call.  You might #ifdef DEBUG your code so the
foreground call is called when you are debugging.  This will prevent
the fork and make it easier to debug your app.

Solution 3
----------
A trick for debugging GL apps while in dbx/edge, do the following sequence
of steps in dbx or the edge command (dbx) window:

	stop in main
	run
	ccall foreground()
	cont

This manual sequence is equivalent ot hardcoding the foreground(3G) call in
your code.  If you run your code more than once in the the same debugging
session, doing "stop in main" is unnecessary.

I have used all three of these techniques and find the second one the easiest
to deal with though the third solution is useful in a pinch compared the 
first solution I offer.

						--- Ciemo