plonka@carroll1.cc.edu (Dave Plonka) (04/25/91)
I need some help with either CreateTask() or CreateProcess(). At present, I'm trying to use CreateTask() as documented in the ROM Kernal Libraries & Devices Manual. However, my routine needs to communicate with devices (serial and narrator). Does my routine then need to be a process since it calls library or device functions even if I open the disk-based libraries in the parent process? I have no documentation on the CreateProcess() function since it is not in either "Libraries & Devices" or "Includes & Autodocs". Accoding to the RKM CreateProc() is in the dos.library. Could someone could provide me with at least the detailed parameter list for CreateProc()? That should give me a place to start. I may be going at this all wrong however. I want to have two tasks, for simultaneous reading & writing to the serial port. Associated with each of these tasks is their own window processing to handle gadgets for either the receive or transmit functions in the task body. I guess I'd like to know what advantage, if any, CreateProc() would provide. Dave Please reply via email to the address below. ----------------------------------------------- plonka@carroll1.cc.edu Dave Plonka ARS: N9HZF -----------------------------------------------
markv@kuhub.cc.ukans.edu (04/25/91)
In article <11388@uwm.edu>, plonka@carroll1.cc.edu (Dave Plonka) writes: > > I need some help with either CreateTask() or CreateProcess(). > > At present, I'm trying to use CreateTask() as documented in the ROM Kernal > Libraries & Devices Manual. However, my routine needs to communicate with > devices (serial and narrator). Does my routine then need to be a process > since it calls library or device functions even if I open the disk-based > libraries in the parent process? No. The only reason you need to be a Process to OpenLibrary() is if you have to worry about going to disk to load the library. If the parent has put the library in memory and you know its there (ie: its holding it open). In most cases, a child can even use a Lib base given to it by its parent, except things like the mathieeexxxx libraries, which keep track of information on a task by task basis. > I have no documentation on the CreateProcess() function since it is not > in either "Libraries & Devices" or "Includes & Autodocs". Accoding to the > RKM CreateProc() is in the dos.library. Yes it is, it is called off of DOSBase. > Could someone could provide me with at least the detailed parameter list for > CreateProc()? That should give me a place to start. > Okay, CreateProc()'s prototype looks like this: struct MsgPort *CreateProc(char *Name, LONG Priority, BPTR SegList, LONG StackSize); Stack size is the size of the stack, Name is a CPTR to a C (null term) string (not a BPTR to a BSTR), and Priority is the priority (-127 to +127) of the process. SegList is the tricky parameter. It is either a BPTR returned by LoadSeg() (used to load external program), ie: BPTR LoadSeg(char *ExternalProgramName); or, if you want to use your own code in memory, you need to dummy a seglist like this: SegBase: DS.L 0 DC.L 16 DC.L 0 CodeStart: #Code starts here. And then convert SegBase to a BPTR ie: Foo = CreateProc("MyProc", 0L, BADDR(SegBase), 4096L); Note in general a "dummy" Seglist requires at least at bit of assembler since there is no way with C to get the data of the SegList in front of your code otherwise. > I may be going at this all wrong however. I want to have two tasks, for > simultaneous reading & writing to the serial port. Associated with each of > these tasks is their own window processing to handle gadgets for either the > receive or transmit functions in the task body. Note that for your specific example, you dont need to have a process. > I guess I'd like to know what advantage, if any, CreateProc() would provide. Well, if later on you wish to use DOS services directly then you have to have a process, otherwise there is no need/advantage. Note that processes are like tasks in that once you CreateXXX() them, they are running on their own, so you have to be careful to kill/exit them properly. Note that 2.0 has a CreateNewProc() function that should be used instead. It is a lot more flexible (you can specify a console window, etc to use), and it can take a straight function pointer or a seglist, you can "roll your own" process in straight C. It works off a general tag list, which is its only "true" parameter. > Dave > Please reply via email to the address below. Ooops, oh well... > ----------------------------------------------- > plonka@carroll1.cc.edu Dave Plonka > ARS: N9HZF > ----------------------------------------------- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jesup@cbmvax.commodore.com (Randell Jesup) (05/14/91)
In article <1991Apr25.144702.30033@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >In most cases, a child can even use a Lib base given to it by its >parent, except things like the mathieeexxxx libraries, which keep >track of information on a task by task basis. Not a good habit to get into, though, in case a library starts having per-task data, or if you run across a new library with per-task data. >string (not a BPTR to a BSTR), and Priority is the priority (-127 to +127) ^^^^ -128 >or, if you want to use your own code in memory, you need to dummy a >seglist like this: > >SegBase: > DS.L 0 > DC.L 16 > DC.L 0 >CodeStart: > #Code starts here. That should be: DC.L 16 ; value doesn't really matter - make it 16 anyways SegBase: ; NOTE: points to pointer to next segment, not size! DC.L 0 ; should be 0 - BPTR to next segment * code starts here - often a jump to real routine. >And then convert SegBase to a BPTR ie: > > Foo = CreateProc("MyProc", 0L, BADDR(SegBase), 4096L); ^^^^^^^^^^^^^^ That's (((LONG) SegBase) >> 2), not BADDR(...). BADDR goes the other direction (BPTR to CPTR). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)