rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (04/15/89)
I don't think there is *ever* a reason to use a Task instead of a Process---or am I wrong? -tom
pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky) (04/15/89)
In article <8459@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >I don't think there is *ever* a reason to use a Task instead of >a Process---or am I wrong? There's no *necessity* that I can think of, but don't tasks carry less overhead? Peter M. Yadlowsky | "Pay no attention to that man Academic Computing Center | behind the curtain!" University of Virginia | pmy@Virginia.EDU |
gilham@polya.Stanford.EDU (Fred Gilham) (04/15/89)
In article <8459@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >I don't think there is *ever* a reason to use a Task instead of >a Process---or am I wrong? > >-tom > With a process you have to fill in some extra blanks. When I wrote a program that used two seperate threads of control, I had no reason to give the second thread any info about working directories, or whatever goes in the process extension of the task structure. So why bother? My understanding is if you want to make calls to dos, you need to be a process. Otherwise you can be a task. Is this right? -Fred Gilham
ugkamins@sunybcs.uucp (John Kaminski) (04/15/89)
In article <8459@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >I don't think there is *ever* a reason to use a Task instead of >a Process---or am I wrong? > >-tom Possibly several. The two that come to mind are the scarcity of the resources involved. If you are running a (gasp) 256K (i.e. original) Amiga, the less memory you use the better. Also, aren't there only 20 process slots? Or are those only processes that are CLI's? Or is there no difference in THOSE two? Around the LoadSeg() problem: One could conceivably AllocMem() for new process space then use a memory copying routine to clone the needed parts, and finding the address of the stuff to copy via FindTask(0) and "peeking into" the struct that is pointed to by the results obtained from that call. Hmmmm....this method has some definite possibilities for emulating fork().
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (04/15/89)
In article <5279@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >Also, aren't there only 20 process slots? Or are >those only processes that are CLI's? Or is there no difference in THOSE two? I believe that's 20 CLI slots, and there is a difference between a CLI and a process. I probably have more than 20 processes on my Amiga right now, and only 5 or 6 of them are CLIs. >Around the LoadSeg() problem: One could conceivably AllocMem() for new process >space then use a memory copying routine to clone the needed parts, and finding >the address of the stuff to copy via FindTask(0) and "peeking into" the struct >that is pointed to by the results obtained from that call. Hmmmm....this >method has some definite possibilities for emulating fork(). I thought about this before recommending LoadSeg and seglist splitting to Kari. If you have no global references in your code, then this should be workable. Just drop the allocated memory into the tc_MemEntry list, and have the finalPC code RemTask(0) (I think that's right). You can't just use the normal process cleanup unless you turn the allocated memory into a proper seglist (I think). If your code has global data accessed as an offset from a register ("small data model"), you should be able to copy the data segment and fix the address register of the new task. This may require some knowledge of the seglist structure, but it must be doable, since Lattice's startup code for resident modules does this. If the code has absolute references, then you can't do it in general, though specific cases might be workable. Of course, most of this has been hashed out on the net many times before, but I was just a cub Amiga programmer then... -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
andy@cbmvax.UUCP (Andy Finkel) (04/18/89)
In article <5279@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >In article <8459@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >>I don't think there is *ever* a reason to use a Task instead of >>a Process---or am I wrong? >> >>-tom > >Possibly several. The two that come to mind are the scarcity of the resources >involved. If you are running a (gasp) 256K (i.e. original) Amiga, the less >memory you use the better. Also, aren't there only 20 process slots? Or are >those only processes that are CLI's? Or is there no difference in THOSE two? There are only 20 CLI slots. You can have as many processes as you have memory for. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "There is no programming problem that cannot be solved by proper "application of the Delete command." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
douglee@becker.UUCP (Doug Lee) (04/24/89)
In article <6615@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >There are only 20 CLI slots. You can have as many processes as you have >memory for. Why only 20 CLI slots?? Will this restriction be eliminated in 1.4 (Yes I have had times when I wanted more). <<<Doug Lee>>>
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/03/89)
In <439@becker.UUCP>, douglee@becker.UUCP (Doug Lee) writes: >In article <6615@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >>There are only 20 CLI slots. You can have as many processes as you have >>memory for. >Why only 20 CLI slots?? Will this restriction be eliminated in 1.4 (Yes >I have had times when I wanted more). Why indeed? Here's a present for you from A. Caleb Gattegno, a member in good standing of DAS (Devil's Advocate Software). ------------- slash here ------------- begin 777 maxcli.zoo M6D]/(#(N,#`@07)C:&EV92X:``#<I\3]*@```-;___\"``$````````!W*?$. M_0(!!P$``'$```"5$2\1O%C(````E@````$```````````!M87AC;&D`4"A?G MP`H6"@!_Z>X`````````````0"DC*````0`8,$^@08$##AH48#"#P80"`R!,V MUY`%'@`$0/`02`"`B(T2`3AQ]4^'"P!GD`S)=Q".2%?]L*D`8J*-1Q,3R@T:" M^8\/B"$L,(@X@B71%$,BL$5Q]H_?4!&\#/XC=X@G(A-520KB:4=$DY'^Q#BI! M<W``.X,A`:35H'"@/(3J'I)Y,\<%FS1BY(21D^?AVX'KT"*4%Q#<I\3]`@&:8 M`@``3@$``&D2X&'0&*0!``!,`0```0```````````&UA>&-L:2YT>'0`"A8*> M`'_3M0````````````!`*2,H``"1I`%AY@V;-7-8@$!31DX9$&GF@`@#HLZ<6 M,F;JL`'!)@T=.FP>UJ&3IB.=/"#HH`E#!\28,&Y`B'DXATZ=,6LFME3YD,X;2 M."#>F`&1YTT=.0IJAI%C$TZ+BW'JE'$SIHP+$""$A)F3YB4;-BCOK&SI$029E M-V4D1H38$@[+,0PE4B3R9`H(.TO3A!$3,N6;B5_?W%%0M([?A6'LB`3J$X2,0 M&C5<=CPA\>=4G4&I6L4JI$S',HK9!I4#PLT;.@H+3W3(,4T;CV7(*&C\Q@U8T MQS`JNB'3$(32W4O)@`CR^DP8NE.N@D@24TX=-V[2N#F3$DW$U$9!W"FY$4[#L M-C"G@D3)YLU%!3%R"@4A)TP;A6)&^OXKEJ5R)):KKUUK$:/&PZH5=%!E\O'D_ MD`L*8`5"$6ZH\48>+"2H(%9!7#5$&"&)`<(1+-%1QAFF*1`0W*?$_0(`````$ M````````````````````````````````````````````````````````````` "_(,`_ `` end ---------- chop here --------------- XREF _LVOOpenLibrary XREF _LVOAllocMem XREF _LVOCloseLibrary XREF _LVOForbid XREF _LVOPermit MAXCLI equ 255 cseg move.l 4,a6 ; get execbase lea DOS_lib,a1 ; get dosbase moveq.l #0,d0 ; version 0 jsr _LVOOpenLibrary(a6) ; and get it move.l d0,a5 ; stick dosbase in an areg move.l 34(a5),a3 ; get ptr to RootNode move.l (a3),d3 ; get BPTR to taskarray asl.l #2,d3 ; turn into APTR move.l d3,a4 ; move into an areg cmpi.l #MAXCLI,(a4) ; see if we've been run before beq enditall ; yes, so exit now! move.l #1024,d0 ; set up to AllocMem 1k move.l #$10000,d1 ; MEMF_CLEAR jsr _LVOAllocMem(a6) ; get memory for new table move.l d0,d7 ; save table addr somewhere beq enditall ; and exit if alloc failed jsr _LVOForbid(a6) ; do dirty deeds, so Forbid move.l (a4)+,d6 ; get old max # CLI's movea.l d7,a1 ; get addr of new table addq.l #4,a1 ; offset past max CLI element subq.l #1,d6 ; make up for dbcc ending at -1 movetable: move.l (a4)+,(a1)+ ; move entry in old table to new dbra d6,movetable ; and go on to next entry movea.l d7,a1 ; get new table addr move.l #MAXCLI,(a1) ; set new max # CLI's asr.l #2,d7 ; turn table addr into BPTR move.l d7,(a3) ; put new BPTR in (RootNode) jsr _LVOPermit(a6) ; Permit now that we're done enditall: move.l a5,a1 ; put DOSBase in a1 for close jsr _LVOCloseLibrary(a6) ; and close dos.library rts dseg DOS_lib dc.b 'dos.library',0 -------------- If you don't think 255 CLIs is enough, wait until you hear the layers library screaming with pain when you are opening or closing #255. :-) -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+