CreateNewProcTags() over sasc and vbcc

[Piru]

You must not do buffered I/O from multiple processes, dos.library filehandles are NOT semaphore protected (nor are most libnix stdio implementations). The behaviour is undefined. If you must output some debug from the sub thread, use kprintf.

Mixing dos.library and stdio I/O result in undefined behaviour.

Don't trust on priorities when doing multiprocess apps, this will break eventually. Use interprocess communcation, see IPC example (Note: This particular example uses 2nd LoadSeg()d function as the 2nd process. It could aswell be another function.)

[Piru]

@kas1e

why CreateNewProcTags do not works over sasc, and the same code works ok on vbcc ?

I guess you missed my point: CreateNewProcTags works just fine, but using Printf for output does not.

Maybe this'll explain it best:

Code: [Select]


#include <dos/dostags.h>
#include <proto/dos.h>
#include <proto/exec.h>
#include <clib/debug_protos.h>

struct Process *player;
static volatile int quit;

__saveds void play_module(void)
{
  kprintf(&quot;ooooo\n&quot;);
  kprintf(&quot;uuuu\n&quot;);
  kprintf(&quot;ieeetss\n&quot;);
  Forbid();
  quit = 1;
}

int main(void)
{
  kprintf(&quot;first\n&quot;);

  player = CreateNewProcTags(
    NP_Entry, &play_module,
    NP_Priority, 1,
    NP_Name, &quot;Player Process&quot;,
    TAG_DONE);

  if (player)
  {
    kprintf(&quot;second\n&quot;);
    while (!quit)
    {
      Delay(20);
    }
    kprintf(&quot;third\n&quot;);
  }
  return 0;
}


compile with: sc nostkchk link test.c lib lib:debug.lib

UPDATE: stack check would screw it up before, sorry for not figuring it out earlier ;-)

[Piru]

I'm using SAS/C Amiga Compiler 6.58

You could try: sc resopt link test.c lib lib:debug.lib
This should eliminate problems from some weird SCOPTS file.

[Piru]

I should prolly remind you that kprintf output is not seen normally (it's using the serial). You should probably use sashimi to grab it.

[Piru]

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.

[Piru]

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.