Yoshiyuki Hasegawa wrote:
> 1. Two code Alpha and Beta are separately compiled.
> 2. Two programs are booted.
> 3. "Send" button is alternately clicked.
>
> As for the demonstration program, the occurrence of the bug is fewer  
> than an original program.
> The bug might not occur in the first boot. They are quit and it  
> boots it again at that time.
> OS is restarted to reproduce the bug or it might have to be  
> recompile as for the programs.


I confirm that this statement sometimes hangs or freezes for a minute  
or so, in OS X 10.5:
SendAppleEvent clas, _"TEXT", @s + 1, len(s)

With no 5th parameter for SendAppleEvent, you are broadcasting the  
AppleEvent to all processes.
In runtime FBSendAppleEvent, the AE is sent to all processes  
discoverable by GetNextProcess(). A little debugging shows that the  
delay is associated with AESend() to a process "mdworker". It remains  
a mystery why mdworker is a bad target for AESend().

The best cure is to target your AE instead of broadcasting it. Add the  
appropriate 5th parameter to SendAppleEvent:
SendAppleEvent clas, _"TEXT", @s + 1, len(s), "Test Program Beta"
SendAppleEvent clas, _"TEXT", @s + 1, len(s), "Test Program Alpha"


If you must broadcast, you will have to edit runtime FBSendAppleEvent  
(in Subs Appearance AEvents.incl), to reject the unhappy target  
mdworker.
Change:
long if ( toNamePtr == 0 ) or ( toName == processName ) // send to all  
or thisPSN
To:
long if ( toNamePtr == 0 and processName != "mdworker") or ( toName ==  
processName ) // send to all or thisPSN



Robert P.