jdg@elmgate.UUCP (Jeff Gortatowsky CUST) (02/02/90)
In article <2612@moondance.cs.uq.oz.au> tonyg@batserver.cs.uq.oz.au writes: >This is a summary of responses regarding fast serial IO handling. > >My question was (put simply): > > I am writing an application using THINK C 4.0 and the Class Libraries. > > What I am trying to do is respond rapidly to data coming in via the > > modem port. When one or more character(s) appears on the modem > > port, I'd like one of my class methods to be called to handle it. > > > > Being a total ignoramus on how THINK C works, I want to know if the above > > can be done without having to poll for IO in the main event loop and call > > the class method from there. > > (This is what I'm doing now, and the response is very sluggish) > >My code now does the following: >* 1024 byte buffers on input and output. >* All IO is processed block at a time. >* I install an Idle task to do the polling and set the sleep value to 0. > The sleep value is 'gSleepTime' I think. >* I still use TextEdit for display purposes. > >After doing the above, the response is exactly the same. I have tried using >a pending asynchronous IO request as was suggested, but it made no difference. > >Tony Gedge - tonyg@batserver.cs.uq.oz.au Being a relative newcomer to McCodin' I know little about serial i/o w/ the mac. But, I have gobs on other machines... Since I've dropped in kinda in the middle of the thread... I shall make a few assumptions? no? Mac serial i/o is 68000 exception driven? ie: Via interupt request and NOT polled. If so, take the serial port over in your code. Set up a table of addresses of the methods for your classes. Use incoming data (say the first byte ? Need more than 255 functions? use a word then) as an indexor into the array (obviously, the array must be non-relocatable), all following data bytes to n (function specific I assume), shove into a queue, or linked list (the queue'll work better). Have your methods simply call a queue manager (with say the functions address array indexor (So the queue manager can know "lengths" of data, or, use the first byte/word of each "event" in the queue). In fact, if one wants to really get "techy" the serial exception handler can itself stuff things into the queue (just use a "watermark" (to stop transmission when reached) to prevent a head/tail collision). In other words, take the serial port over as a EVENT manager. Also, if one has control over the client machines software (ie: your writing some type'a server/client apps) one can employ data compression at both ends rapidly w/ Lempel-Ziv-Welch compressions... Also, stuff it into the exception handler. Hope this helps... Also, anytime w/ relativly slow (by todays standards) Cpu's using items like fontz and the like will make things "appear" slower. W/ the baselines and the like. 68000 exceptions as well take a tremendous amount of CPU time as compared to Jsr's. This is due to the fact they plop a whole loada stuff' onto the supervisor stack. -- Jeff Gortatowsky-Eastman Kodak Company .....rochester!kodak!elmgate!jdg (use uuhosts or such to find path to rochester) Eastman Kodak makes film not comments. Therefore these comments are mine not theirs.