Loosing signals from STRING_KIND on 68000 machine

[Sim085]

So I decided to test my program on a real A500 and I noticed some signals from the STRING_KIND gadget hook are being lost.

I have simplified the code so that I can focus on the issue. The hook code is as follows;

ULONG press (struct Hook *hook, struct SGWork *obj, ULONG *msg)
{
    c = obj->Code;   // c is global variable.
    Signal(task, signal);
    return 0;
}

My handler is as follows:

int s = Wait(1L << myWindow->UserPort->mp_SigBit | signal);
...
else if(s & singal)
{
   char t = c;
   FreeSignal(signal);
   {
      char *input = ((struct StringInfo *)(name->SpecialInfo))->Buffer;
      printf("%c-%d\n", t, strlen(input));}
   }
...

On a 68020 machine everything works fine. Any sentence I type the character is printed on screen and next to it the length of the string.

However on a 68000 or 68010 I notice some signals are missing (depending on how fast I type).

Example when I type slowly the text "Amiga" I get the following:

A - 1
m - 2
i - 3
g - 4
a - 5

But if I type the same string fast I get the following;

m - 2
a - 5

What am I doing wrong?

[jotd]

signal or singal?

maybe race condition? is it normal to FreeSignal before accessing the buffer? (just an idea). Freeing the signal after that may avoid the race condition ... or not

[thomas]

I see two possible reasons.

Firstly you have a call to FreeSignal in the code which for me seems completely out of sync. At least there is no corresponding AllocSignal.

In any case you make a big mistake in function calls. AllocSignal and FreeSignal act on signal numbers, that is a BYTE value between 0 and 31 or -1 for failure. Wait() and Signal() on the other hand act on signal masks, i.e. a 32bit ULONG with the n'th bit set. So for example if AllocSignal returns bit #8, the corresponding signal mask is 0x100 or 256. Now if your Wait() and Signal() logic works, then your above code gives the signal mask to FreeSignal instead of the signal number. This is wrong. Because a signal with number 256 does not exist, the FreeSignal call does nothing. If you do AllocSignal/FreeSignal this way in a loop, you quickly run out of signals because each call to FreeSignal fails.

The other possible reason is speed. A signal is not a message. A signal is just a bit in the task structure. Once a signal is set, it remains set until somebody clears it. The Wait() call does clear the signal. But if you type so fast that your main routine cannot catch each signal with Wait() then every other signal is lost.

If your app depends on the fact that each "signal" is received, then an AmigaOS signal is not the right method to use. In this case you have to send a message to a message port. The port will queue all messages until they are processed. BTW, a port uses signals, too. The port's signal indicates that new messages have arrived. It does not say how many. It's just one bit, it can be on or off. It cannot hold more information.

One remark: if the only intention behind all this effort is debugging, then you should rather use kprintf in your edit hook. Then you don't need to care about signal or message forwarding. Your debug output will appear on the serial port or, if you run Sashimi first, in a separate window.

[Sim085]

Sorry that was a typo, did not copy paste that line. Can confirm it is signal.

Originally Posted by jotd

signal or singal?

I clearly misunderstood what FreeSignal is meant to do. I thought it was the equivalent of GT_ReplyIMsg, i.e. - that when I received a signal I needed to release it. I have now removed this and instead moved it to the section where I clean resources when closing the application. I have also corrected the mistake and no longer FreeSignal(signal) but FreeSignal(signalId) where signalId store the result returned from AllocSignal(). Thank you for pointing this out.

Originally Posted by thomas

I see two possible reasons.

Firstly you have a call to FreeSignal in the code which for me seems completely out of sync. At least there is no corresponding AllocSignal.

In any case you make a big mistake in function calls. AllocSignal and FreeSignal act on signal numbers, that is a BYTE value between 0 and 31 or -1 for failure. Wait() and Signal() on the other hand act on signal masks, i.e. a 32bit ULONG with the n'th bit set. So for example if AllocSignal returns bit #8, the corresponding signal mask is 0x100 or 256. Now if your Wait() and Signal() logic works, then your above code gives the signal mask to FreeSignal instead of the signal number. This is wrong. Because a signal with number 256 does not exist, the FreeSignal call does nothing. If you do AllocSignal/FreeSignal this way in a loop, you quickly run out of signals because each call to FreeSignal fails.

The other possible reason is speed. A signal is not a message. A signal is just a bit in the task structure. Once a signal is set, it remains set until somebody clears it. The Wait() call does clear the signal. But if you type so fast that your main routine cannot catch each signal with Wait() then every other signal is lost.

If your app depends on the fact that each "signal" is received, then an AmigaOS signal is not the right method to use. In this case you have to send a message to a message port. The port will queue all messages until they are processed. BTW, a port uses signals, too. The port's signal indicates that new messages have arrived. It does not say how many. It's just one bit, it can be on or off. It cannot hold more information.

One remark: if the only intention behind all this effort is debugging, then you should rather use kprintf in your edit hook. Then you don't need to care about signal or message forwarding. Your debug output will appear on the serial port or, if you run Sashimi first, in a separate window.