Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!adobe!hawley From: hawley@adobe.COM (Steve Hawley) Newsgroups: comp.sys.mac.programmer Subject: Re: Is there a defacto standard for 'drop ins'? Message-ID: <13225@adobe.UUCP> Date: 26 Mar 91 23:03:15 GMT References: <1CE00001.aolmdnz@tbomb.ice.com> <13094@adobe.UUCP> <13180@adobe.UUCP> Reply-To: hawley@adobe.UUCP (Steve Hawley) Organization: Adobe Systems Incorporated, Mountain View Lines: 76 In article d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >What keeps you from reading blocksa of 1 byte ? And what keeps the >host application from passing pointers into its own buffers ? It tells >the filter how much there is to read, and the filter tells the host >how much it wants... Nothing *keeps* you from reading one byte blocks. You're right. But tell me, do _you_ define getchar like this? int mygetchar() { char c; if (read(0, &c, 1)) return(c); else return(EOF); } Just for kicks I wrote a program to consume standard input (under UNIX) and found that using standard getchar takes .2 seconds of user time and .2 seconds of system time to read the man page for the c shell. The same program with mygetchar used instead requires 3.4 seconds of user time and 43.4 seconds of system time. Now, as a final trick, I modified mygetchar() to use a 8192 bytes buffer instead of a 1 bytes buffer to simulate a drop in module with a fairly generous buffer size. It took .1 seconds of user time and .1 seconds of system time. Not significantly different over a 75K file. > than it is to write a correct block-based filter, and you are forcing > everyone who writes a drop in module to do their own buffer handling. > >Do I ? No, you're right. You don't _have_ to write buffer handling routines. See above for what happens when you don't have them, and if the only way to get buffered IO is by putting it in the drop in module and stream oriented I/O is the most appropriate means of getting bytes across then your application will be much bigger than it has to be because for every drop in module, there will be stream I/O code with buffer management. Now before we start getting into another series of "great taste/less filling" arguments, please keep in mind that I am not rabidly against block style I/O, nor am I rabidly for stream-style buffered I/O. Let's be computer scientists for a minute, OK? Can you implement stream-style buffered I/O using block style I/O routines? Yes? Good. Can you implement block-style unbuffered I/O routines with stream routines? Let's not see the same hands... Right, you can. Gosh! They're equivalent! So why use one over the other? Only your application will dictate which is more appropriate. If I write a terminal emulator and decide that I want to allow drop in modules for transfer protocol or emulation, I'm probably going to want to use stream IO. If I write something like PhotoShop, I'd probably want block IO (in fact, I'd probably rather have the pointer to a data structure). The important point (do I really have to type this for the third time?) which is the answer to the original question of "why is there no standard means of doing drop-in modules" is that there is no standard task that needs to be done by a drop-in module. The needs are different, so therefore are the means of satisfying that need. My original article was meant to pose a general, not universal, method for handling communication between a parent application and drop-in modules. I chose a stream model for a few reasons: 1) It's simple to interface to 2) It's reasonably efficient for a wide range of tasks 3) The directional nature of it allows for easy connection (similar to pipes) bewteen modules. 4) Provides a "feel" similar to UNIX stream IO. I realy didn't mean for this to get into so much "block IO! Nyah! stream IO! Nyah!" traffic. Really. Steve Hawley hawley@adobe.com -- "Did you know that a cow was *MURDERED* to make that jacket?" "Yes. I didn't think there were any witnesses, so I guess I'll have to kill you too." -Jake Johansen