Task exit: Forbid() without Permit()

[dissident]

Hi,

actually I try to run some old OCS demos on an AGA machine. After these demos return to the WB, the system is frozen. I found out, that most of them use Forbid(), but returned without calling Permit().

Is there a way to detect, if a task exits, that it has not called Permit() after calling a Forbid() ?

[Toni Wilen]

Forbid state should automatically go away when task that executed Forbid() is removed or if something forces task switch (like use of Wait()). Forbid (and Disable) is per-task state.

[thomas]

Forbid()
ReplyMsg(wbmsg)
return

is the normal ending of a program started from Workbench.

Forbid just sets a flag in the task structure. When the task ends, its Forbid status vanishes along with the task structure.

The above sequence of commands assures that the replied message can be received by Workbench only after the task has already ended.

This is not the cause of your freezes. Of course this part of the program should never be executed if it is run from the Shell. But even if you manage to call this from the Shell, it does not freeze the machine.

[dissident]

Originally Posted by Toni Wilen

Forbid state should automatically go away when task that executed Forbid() is removed or if something forces task switch (like use of Wait()). Forbid (and Disable) is per-task state.

Yes, on pre OS2.0 systems, the Forbid state seems automatically to go away. But on OS 3.0, the WB doesn't freeze, if a Permit() is called right after the demo returned from its execution.

[dissident]

Originally Posted by thomas

Forbid()
ReplyMsg(wbmsg)
return

is the normal ending of a program started from Workbench.

Forbid just sets a flag in the task structure. When the task ends, its Forbid status vanishes along with the task structure.

The above sequence of commands assures that the replied message can be received by Workbench only after the task has already ended.

This is not the cause of your freezes. Of course this part of the program should never be executed if it is run from the Shell. But even if you manage to call this from the Shell, it does not freeze the machine.

Maybe a misunderstanding. The demo is not called by an icon from WB. There is no WB-message that has to be replied. It is called from a shell window on the WB.

[dissident]

Originally Posted by thomas

Forbid()

Forbid just sets a flag in the task structure. When the task ends, its Forbid status vanishes along with the task structure.

Maybe this could be a solution. Which flag is set in the task structure if Forbid was called ?

[meynaf]

Originally Posted by dissident

Maybe this could be a solution. Which flag is set in the task structure if Forbid was called ?

IIRC this is TDNestCnt. But it's a counter, not a mere flag (calls to Forbid must be matched by the same number of calls to Permit).

[StingRay]

Originally Posted by dissident

Yes, on pre OS2.0 systems, the Forbid state seems automatically to go away. But on OS 3.0, the WB doesn't freeze, if a Permit() is called right after the demo returned from its execution.

There must be another reason for the freeze, I just tried returning to the system without calling Permit() on my 3.1 machine and it worked without any problem.
Many old OCS demos trash memory and/or don't restore interrupt/hardware vectors correctly which can lead to problems such as system freezes.

[dissident]

Originally Posted by meynaf

IIRC this is TDNestCnt. But it's a counter, not a mere flag (calls to Forbid must be matched by the same number of calls to Permit).

Many thanks, meynaf. That's exactly what I need. I could check the counter value, and if it's not NULL, then there are one or more Permits missing. I guess Forbid() increments and Permit() decrements the counter by 1.

[Toni Wilen]

Why do you still think permit have anything to do with this problem? It does not. It can't!

[dissident]

Originally Posted by StingRay

There must be another reason for the freeze, I just tried returning to the system without calling Permit() on my 3.1 machine and it worked without any problem.
Many old OCS demos trash memory and/or don't restore interrupt/hardware vectors correctly which can lead to problems such as system freezes.

Generally you are right, StingRay. Most old OCS demos overwrite or trash memory or don't resore the hardware registers properly. But I make a copy of the whole CHIP memory (lower 1MB) before I execute the demo and restore it after the exit of the demo. Additionally I save the interrupts/DMACON/CIA registers and restore them also after the exit of the demo. In this case, using an additional Permit() was the solution. But it may be a random thing.

The demo is this one: http://www.pouet.net/prod.php?which=13856

[Toni Wilen]

Was task structure or execbase also in stored/restored part of chip ram?

[dissident]

Originally Posted by Toni Wilen

Why do you still think permit have anything to do with this problem? It does not. It can't!

Because I had a similar case in this startup code on OS3.x here:

 move.l    d0,-(sp) 
      
          tst.l    returnMsg        ; Is there a message? 
          beq.s    exitToDOS        ; if not, skip... 
      
          move.l    4.w,a6 
              jsr    _LVOForbid(a6)          ; note! No Permit needed! 
      
          move.l    returnMsg(pc),a1 
          jsr    _LVOReplyMsg(a6) 
      
      exitToDOS 
          move.l    (sp)+,d0        ; exit code 
          rts

A Permit() before rts is needed to prevent a frozen WB where you can't click on icons any more or they don't react any more.

[Toni Wilen]

Thats standard official startup code. Every program that runs from WB uses it (like was already mentioned above).

You sure there was not some memory corruption or some other random problem that made task exit to hang? (=Forbid state didn't go away)

[ross]

Originally Posted by dissident

A Permit() before rts is needed to prevent a frozen WB where you can't click on icons any more or they don't react any more.

Now you have intrigued me because I do not use Permit() before rts and it normally works.

If i'm not wrong it's mandatory to do the ReplyMsg() in Forbid() state and exit w/o a Permit() to prevent WB prematurely unloadseg the exe.

[meynaf]

But does the task really exit ? If run from WB directly, it does. If run from some cli, then the cli is the current task and it does not get deleted after the program exits. Besides, the demo might leave the forbid/permit counter in any state...

[StingRay]

Originally Posted by dissident

Generally you are right, StingRay. Most old OCS demos overwrite or trash memory or don't resore the hardware registers properly. But I make a copy of the whole CHIP memory (lower 1MB) before I execute the demo and restore it after the exit of the demo. Additionally I save the interrupts/DMACON/CIA registers and restore them also after the exit of the demo. In this case, using an additional Permit() was the solution. But it may be a random thing.

The demo is this one: http://www.pouet.net/prod.php?which=13856

I have checked, the intro lacks blitter waits which are most likely the reason for the system freeze upon exit! Just saving hardware registers etc. is not enough to let the intro run properly on anything else than a plain 7 MHz Amiga, you need to add the blitter waits!

[dissident]

Originally Posted by Toni Wilen

Thats standard official startup code. Every program that runs from WB uses it (like was already mentioned above).

Yes, I use nearly the same code, but with an additional Permit. This method is confirmed by the Autodocs 1.3/2.0/3.5:

Calls to Forbid() nest. In order to restore normal task rescheduling, the programmer must execute exactly one call to Permit() for every call to Forbid().

Originally Posted by Toni Wilen

You sure there was not some memory corruption or some other random problem that made task exit to hang? (=Forbid state didn't go away)

No, in that case, the demo worked properly and didn't corrupt memory areas. My tester on her A4000-060 told me, that without the Permit(), memory used by the task is not given back to the system.

[dissident]

Originally Posted by Toni Wilen

Was task structure or execbase also in stored/restored part of chip ram?

The main program which loads and executes the demo is in FAST memory, so I guess the task structure, too. The execbase is in lower CHIP memory.

[Toni Wilen]

Originally Posted by dissident

Yes, I use nearly the same code, but with an additional Permit. This method is confirmed by the Autodocs 1.3/2.0/3.5:

Missing Permit() is REQUIRED when program was started from WB. Check Workbench chapter in RKRM.

When WB gets the message back, it will UnloadSeg() and free all memory. If task switching is enabled, program may get unloaded before following instruction(s) are executed.