tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (02/05/91)
I have the following requiremnts: A parent process that starts up children processes and waits for them before continuing. The child might require up to 50 arguments. These arguments concatenated togther could total 1000 characters. The parent needs to know if the child succeeded or failed (ie. returns 0 if okay, anything else if failed). Here's the catch the child must be an independant program capable of being run on its own from CLI (just like COPY, MAKEDIR, etc.) Which Amiga function will I need to call in the parent program to start up the child to accomplish this? It can be either 1.3 or 2.0. Does anybody know the string length limit for the 2.0 System() call? Is it the same as a CLI command 256? Thanks in advance, Tal Lancaster tll@tybalt.caltech.edu
Jay@deepthot.UUCP (Jay Denebeim) (02/05/91)
In article <1991Feb4.171549.28531@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >I have the following requiremnts: > >A parent process that starts up children processes and waits for them >before continuing. The child might require up to 50 arguments. These >arguments concatenated togther could total 1000 characters. The parent >needs to know if the child succeeded or failed (ie. returns 0 if okay, >anything else if failed). Here's the catch the child must be an independant >program capable of being run on its own from CLI (just like COPY, MAKEDIR, etc.) Under 2.0 you've got two choices: System() Execute() System executes syncronously, and returns the return code of the child task to the caller. Execute executes asyncronously, and returns success of the launching of the program. So, if you need to launch several processes at the same time, execute is your only choice. If only one process is needed, System will do what you want. As far as passing parameters go, I would suggest concidering opening up a public port, and have the child ask for the parameters. You have to open a port anyway in the execute case, as there is no mechinism defined to return the return code in the Execute case. If I was writing the code, it would go something like this: Parent: Open port Execute child (either passing the address of the port on the command line, or the name of the port if public) Forever Wait on Port While message available Process message If message=child complete break; end end Child: Find Port Ask for Parms Do my thing Tell parent byebye exit In the system case: Parent: rc = System child Child: do my thing return rc It all depends on what you want to do. Since I like multi-tasking, I'd probably start the child and then do more work while the child was doing its thing. > >Which Amiga function will I need to call in the parent program to start up >the child to accomplish this? It can be either 1.3 or 2.0. > >Does anybody know the string length limit for the 2.0 System() call? Is it the >same as a CLI command 256? Sorry, don't know for sure. Reading between the lines of the autodoc, I'd say same limitations as the CLI, but I'm not sure that the 256 byte limit in the CLI is still there. Its not BCPL anymore. > >Thanks in advance, > >Tal Lancaster >tll@tybalt.caltech.edu -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: mcnc!wolves!deepthot!jay ====== BBS:(919)-460-7430 VOICE:(919)-460-6934
andy@cbmvax.commodore.com (Andy Finkel) (02/06/91)
In article <Jay.9138@deepthot.UUCP> Jay@deepthot.UUCP (Jay Denebeim) writes: >In article <1991Feb4.171549.28531@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >Under 2.0 you've got two choices: > System() > Execute() > >System executes syncronously, and returns the return code of the child >task to the caller. > >Execute executes asyncronously, and returns success of the launching of >the program. Execute() under 1.3 or 2.0 is sync. And for compatibility, you can't get return codes :-( System() under 2.0 can be sync or async, your choice. And, if used sync style, you can even get return codes passed back from the program. >>Does anybody know the string length limit for the 2.0 System() call? Is it the >>same as a CLI command 256? The limit is currently 512 characters. We almost made it unlimited, but ran into compatibility problems with some 3rd party products that know too much about dos for their own good. I have a plan to handle that which may get put in sometime in the future, though. >>Tal Lancaster >>tll@tybalt.caltech.edu andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
markv@kuhub.cc.ukans.edu (02/06/91)
>>Under 2.0 you've got two choices: >> System() >> Execute() It might be good to mention that Execute() is also available under 1.3. Also ANSI system() is available too. > Execute() under 1.3 or 2.0 is sync. > And for compatibility, you can't get return codes :-( > > System() under 2.0 can be sync or async, your choice. And, if > used sync style, you can even get return codes passed back from > the program. system() is sync also, but any such beast can be made Async by doing someting like: Execute("run foocommand", 0L, 0L); Return codes are still a problem. And one can play games with LoadSeg()/CreateProc(). If you have Lattice/SAS you can also check into the fork() family, which gives you some control over return codes, etc. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (02/07/91)
markv@kuhub.cc.ukans.edu writes: >>>Under 2.0 you've got two choices: >>> System() >>> Execute() >It might be good to mention that Execute() is also available under >1.3. Also ANSI system() is available too. > >> Execute() under 1.3 or 2.0 is sync. >> And for compatibility, you can't get return codes :-( >> >> System() under 2.0 can be sync or async, your choice. And, if >> used sync style, you can even get return codes passed back from >> the program. >system() is sync also, but any such beast can be made Async by doing >someting like: > Execute("run foocommand", 0L, 0L); >Return codes are still a problem. And one can play games with >LoadSeg()/CreateProc(). >If you have Lattice/SAS you can also check into the fork() family, >which gives you some control over return codes, etc. >-- No thank-you!!! I implore you to stay away from SAS's fork() family until they have it fixed! I can show you a few lines of innocent looking code that will trash your hard-drive (or the disk of your cwd). It trashed my hard-drive 5 times before I track the problem to fork(). >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Mark Gooderum Only... \ Good Cheer !!! >Academic Computing Services /// \___________________________ >University of Kansas /// /| __ _ >Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it >Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... >Internet: markv@kuhub.cc.ukans.edu >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tal Lancaster tll@tybalt.caltech.edu
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (02/07/91)
In article <Jay.9138@deepthot.UUCP> Jay@deepthot.UUCP (Jay Denebeim) writes: >In article <1991Feb4.171549.28531@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >>I have the following requiremnts: >> >>A parent process that starts up children processes and waits for them >>before continuing. The child might require up to 50 arguments. These >>arguments concatenated togther could total 1000 characters. The parent >>needs to know if the child succeeded or failed (ie. returns 0 if okay, >>anything else if failed). Here's the catch the child must be an independant >>program capable of being run on its own from CLI (just like COPY, MAKEDIR, etc.) > IMHO, System() and Execute() are gross, because of the overhead invol- ved. It's not all that difficult to use LoadSeg() and CreateProc(). Besides parameters can be passed to the child process via the tc_UserData field in the task control block.
andy@cbmvax.commodore.com (Andy Finkel) (02/07/91)
In article <1991Feb6.190231.1116@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > IMHO, System() and Execute() are gross, because of the overhead invol- >ved. It's not all that difficult to use LoadSeg() and CreateProc(). Besides >parameters can be passed to the child process via the tc_UserData field in the >task control block. System and Execute overhead aren't that much more; in fact, if you want a CLI process, the overhead is unavoidable. Since System and Execute (under 2.0) are in rom, there's no disk based overhead, like under 1.3. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
jesup@cbmvax.commodore.com (Randell Jesup) (02/07/91)
In article <1991Feb6.190231.1116@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > IMHO, System() and Execute() are gross, because of the overhead invol- >ved. It's not all that difficult to use LoadSeg() and CreateProc(). Besides >parameters can be passed to the child process via the tc_UserData field in the >task control block. Sure, if and only if you are certain it's code you wrote. If you need to execute an arbitrary or existing command, you need a proper environment. CreateNewProc can create such an environment, however it doesn't handle aliases, command paths, shell variables, internal shell commands, etc, etc. Use the appropriate tool for the appropriate job. System() is quite appropriate for a class of jobs, CreateProc/CreateNewProc() are appropriate for a different class. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
giguere@csg.uwaterloo.ca (Eric Giguere) (02/07/91)
In article <1991Feb6.190231.1116@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > IMHO, System() and Execute() are gross, because of the overhead invol- >ved. It's not all that difficult to use LoadSeg() and CreateProc(). Besides >parameters can be passed to the child process via the tc_UserData field in the >task control block. One thing I'm not sure about, though: does the parent have to remain running to eventually do an UnloadSeg() on the child process? The AmigaDOS docs aren't too clear on that one... I would like to know. -- Eric Giguere giguere@csg.UWaterloo.CA Quoth the raven: "Eat my shorts!" --- Poe & Groening
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (02/08/91)
In article <1991Feb7.001246.5257@maytag.waterloo.edu> giguere@csg.uwaterloo.ca (Eric Giguere) writes: >One thing I'm not sure about, though: does the parent have to remain >running to eventually do an UnloadSeg() on the child process? The AmigaDOS >docs aren't too clear on that one... I would like to know. > >-- >Eric Giguere giguere@csg.UWaterloo.CA > Quoth the raven: "Eat my shorts!" --- Poe & Groening Yeah, I wonder about this too. I thought that when the process died the cleanup code would automatically do an UnLoadSeg. But from some of my earlier projects - I remember that the available memory did not increase after a child process died to reflect that which was tied up in LoadSeg. I was saving a copy of the value returned from LoadSeg in tc_TrapData (I think) then explicitly unloading it at the end. This may have been fixed under 2.0, or maybe I was doing something wrong. Besides, I terribly hacked my startup code to be very small. Don't recall though axing anything to do with cleanup. I would like to get this cleared up. Jeff
jesup@cbmvax.commodore.com (Randell Jesup) (02/08/91)
In article <1991Feb7.001246.5257@maytag.waterloo.edu> giguere@csg.uwaterloo.ca (Eric Giguere) writes: >In article <1991Feb6.190231.1116@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >> IMHO, System() and Execute() are gross, because of the overhead invol- >>ved. It's not all that difficult to use LoadSeg() and CreateProc(). Besides >>parameters can be passed to the child process via the tc_UserData field in the >>task control block. > >One thing I'm not sure about, though: does the parent have to remain >running to eventually do an UnloadSeg() on the child process? The AmigaDOS >docs aren't too clear on that one... I would like to know. If you start something with CreateProc, yes, or the child must explicitly unload itself (under Forbid()!) If started with CreateNewProc, (assuming a seglist and not an entry), you can tell it to unload the code on exit. For Execute() and System(), there no need to do anything (they spawn a full shell). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
rosenber@ra.abo.fi (Robin Rosenberg INF) (02/08/91)
In article <1991Feb7.001246.5257@maytag.waterloo.edu> giguere@csg.uwaterloo.ca (Eric Giguere) writes: >One thing I'm not sure about, though: does the parent have to remain >running to eventually do an UnloadSeg() on the child process? The AmigaDOS >docs aren't too clear on that one... I would like to know. You obviously cannot UnloadSeg() yourself. However you can make a copy of the entry/exit code, hang the copy onto the task's tc_MemEntry list. Then you give the copied code to CreateProc(). When the process finishes control returns to the copied code which UnloadSeg()s and exists. The memory occupied by the copied code is freed by exec when the process terminates. This is essentially what the SAS C cback startup module does. Take a look at it. -------- Robin
Jay@deepthot.UUCP (Jay Denebeim) (02/08/91)
In article <18606@cbmvax.commodore.com> andy@cbmvax.commodore.com (Andy Finkel) writes: > >Execute() under 1.3 or 2.0 is sync. >And for compatibility, you can't get return codes :-( > >System() under 2.0 can be sync or async, your choice. And, if >used sync style, you can even get return codes passed back from >the program. Arrggg... Andy, take a look at the autodocs then, I read 'em before making my post. They sound like its the other way In exec 'requires RUN to be in C:' made me think it was async, System returns the return code, which made me think it was sync... By the way, you can't have return code and async can you? >-- >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: mcnc.org!wolves!deepthot.uucp!jay ====== BBS:(919)-460-7430 VOICE:(919)-460-6934
jesup@cbmvax.commodore.com (Randell Jesup) (02/09/91)
In article <Jay.9842@deepthot.UUCP> Jay@deepthot.UUCP (Jay Denebeim) writes: >Arrggg... Andy, take a look at the autodocs then, I read 'em >before making my post. They sound like its the other way >In exec 'requires RUN to be in C:' made me think it was async, >System returns the return code, which made me think it was >sync... I've modified the autodocs to make it more clear. >By the way, you can't have return code and async can you? Nope. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)