🚀 go-pugleaf

In article <8907032258.AA16367@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes:
>Francois Rouaix <rouaix@inria.inria.fr> in message <1364@inria.inria.fr> writes
>
>> I  have a doubt on the possibility that UnLoadSeg() might
>> Wait() somewhere. Does anybody knows for sure ?
>
>There is no reason why UnLoadSeg would want to call Wait().

	For overlaid modules it will Wait().

>> callsys Forbid
>> * setup UnLoadSeg
>> callsys UnLoadSeg
>> moveq.l 0,d0
>> rts
>
>What happened to "callsys Permit"? Jette dans l'oubliette?

	Not needed: he's exiting his task with that rts, so his task will
go away, and the Forbid() dies at that time also.

>I think there is a logic mistake here. Does UnLoadSeg() also remove the task
>associated with it? If so, then the Forbid() is immediately obsoleted, the
>memory associated with the task gets freed, but somehow you still insist
>running code within a task that does not exist anymore. I am surprised your
>code runs some of the time, it should fail instantly every time.

	UnLoadSeg() has no knowlege of tasks (think about it).  However, it
is safe to reference memory that has been freed under a Forbid() so long
as it isn't the first N (where N=8) bytes of the freed hunk.  For seglists,
the first 8 bytes are the segment size and next segment BPTR, so the code/
data isn't touched.  Once you explicitly or implicitly break the Forbid
(via Permit or Wait()), the memory can be trashed.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"