Welcome, Guest. Please login or register.

Author Topic: CreateNewProcTags() over sasc and vbcc  (Read 5511 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: CreateNewProcTags() over sasc and vbcc
« Reply #14 from previous page: May 13, 2006, 10:11:24 AM »
It was the stack check code screwing it up. nostkchk cures it.

More explanation: It would compare the stack pointer for overflow at play_module, and if the pointer was lower than the limit set at startup code, it would set up a requester and exit. However, play_module was run on context of a second process, and thus stack pointer was randomly either before or after the main task stack. This is why it failed randomly.

I've updated the code to poll some variable for termination aswell, far from perfect but at least it should never crash now.
 

Offline kas1eTopic starter

Re: CreateNewProcTags() over sasc and vbcc
« Reply #15 on: May 13, 2006, 11:05:13 AM »
@piru
thanks, with 'nostkchk' works always just fine :) also maybe you can give me a little brief about Forbid() and Permit() calls ? I understand from docs of course, that forbid() - forbid task resheduiling, and while not found Permit(); will dissallow resheduiling, but where it's necessary in real life ? i mean in all of my lame srcs i do not use Forbid/Permit, but all works ok. where it necessary really ?
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: CreateNewProcTags() over sasc and vbcc
« Reply #16 on: May 13, 2006, 11:26:31 AM »
It is necessary if you don't want to have random crashes.

For example in the edited example the Forbid() call is absolutely needed (and without matching Permit() call, even).

If there was no Forbid() the quit flag would be set to 1, and then if rescheduling would occur the main program would get to run. When the main program finishes, the shell/Workbench will free the seglist. Now imagine if the sub process would then get scheduled to run. The memory holding the seglist would be free and something else might have reused it already -> crash.

Normally Forbid() call must have a matching Permit() call, but end of process is special case, here you can do Forbid() and let process end handle it (evetually RemTask(NULL) takes care of the pending Forbid).

If you are performing operations from multiple processes, or you're scanning system lists you need to have arbitration. System lists require use of Forbid()/Permit(). Your own stuff can potentially use semaphores.