#Multiple WaitPort()s
7 messages in this thread
My translation of Steve's Serial module to BM works and I am
talking to my modem (yay!). But I am stymied on how to avoid a
BusyWait.
Normally you do a WaitPort() to sleep until you see an Intuition
event and process it. Now I also want to do a WaitPort() on my serial
read port. If I sleep waiting for Intuition the serial buffer can
blow out. If I sleep waiting for the serial port how can I react to
Intuition events? A BusyWait kind of loop with a couple GetMsg()s
solves the problem but…
Any ideas? I've got a feeling this is pretty simple. — Art
Art,
Try this. Yuo will have to change the second siganl sert to be your serial
port, where here I am waiting for two window.Userports. But it should still
work. This has not given me any problems yet.
Please let me know how it works. PROCEDURE MainLoop; VAR
msg : IntuiMessagePtr;
BEGIN
WHILE NOT stop DO
sig := Wait(SignalSet{CARDINAL(dwptr^.UserPort^.mpSigBit)}+
SignalSet{CARDINAL(gwptr^.UserPort^.mpSigBit)});
LOOP
msg := GetMsg(gwptr^.UserPort^);
IF msg = NIL THEN
msg := GetMsg(dwptr^.UserPort^);
IF msg = NIL THEN
EXIT; END;(*IF msg = NIL*)
END;(*IF msg = NIL*)
ProcIMsg(wproc, msg);
END;(*LOOP*)
END;(*WHILE*) END MainLoop; By the way, ProcIMsg is a prewritten procedure
from Benchamrks simpleIDCMP module. If you dont have that then you would have
to handle making copies of your message's class, code, qualifier BEFORE you
Reply to the message, and then process these yourself
Hope this helps,
Jim Vogel
It's quite simple! Instead of using WaitPort, use Wait. Wait accepts a mask
of signals to wait upon. You gotta set up a signal mask comprised of the
Intuition port's signal and your Serial port signal (that's what WaitPort
does, really). For an example of how to do that, look at my EtchAsketch
program. Look for calls to procedures beginning with "ListenTo". In that
program I wait on Intuition and the Joyport at the same time.
– Steve –
Thanks alot, Steve (and Jim V.) for the helpful tip with Wait(). Like I
thought, it is quite simple to monitor multiple ports but I never would of
found out how on my own.
Re: Your Serial routines. My port was identical to yours (not much chance
for variation) with the exception that I do make the buffer length a
CARDINAL. It might not be likely but the user module could request a read
from the serial port that exceeds the maximum length of the buffer. If you
agree that this is bad I'll undertake to U/L the slightly modified version.
This is the only mod:
PROCEDURE SerWrite(VAR Buffer : ARRAY OF BYTE; Length: CARDINAL); (* and
SerRead *)
WITH WriteRequest^ DO
IOSer.ioLength := LONGCARD(Length);
END;
This raises a question. With the smaller 32K buffer allowed by Benchmark
would high speed serial communications be tougher? MIDI is 31,250BPS.
That's one second to fill the buffer – or am I confusing units somewhere.
Finally, I'll continue to whack at your RawDemo for Benchmark. I was anxious
to get the serial port flying 'cuz I am working on a nifty little utility
that HASN'T BEEN DONE YET! — Art
Yes, you're confusing units……..MIDI is 31,250 BITS per second, that
should then take around 10 seconds to fill the buffer (don't forget the start
and stop bits + 8 bits per byte).
Art,
The main thing to remember is that when you wait for multiple classes of
events, and your task 'wakes up', you have to keep doing a GetMsg() until
there are no further outstanding messages. You probably want to handle the
most critical ones first, but you can get all the outstanding messages from
all the classes, no matter which one first awakened the task. (speaking of
Wait() here, not sure about WaitPort()).
-larry
Good point, Larry. Thanks. — ARt