Date: Sun, 28 Sep 1997 18:34:25 +0200 (IST) From: Eli Zaretskii To: Michael Mauch cc: djgpp AT delorie DOT com Subject: Re: DJGPP, interprocess communication, and DPMI In-Reply-To: <3432dbba.55370862@news.uni-duisburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 26 Sep 1997, Michael Mauch wrote: > At the moment, my latest version of the TSR has only a 100 byte buffer, > but up to nearly 64 KB should be possible as well. Relax, a 4KB buffer is already enough to make it workable. Many Unix systems have a 4KB-large buffer for pipes, so it's not bad at all. > The problem is that > this means that the TSR has to reserve this buffer in plain DOS (before > starting Windows), because we can only have shared memory between > different DOS boxes if it's allocated in plain DOS. You could allocate and deallocate memory using DOS calls as needed. I suspect that in most cases the two programs can poll the pipe for messages fastly enough to never let more than a few hundreds of bytes accumulate there before they are gobbled by the other end of the pipe. > With the current 100 byte buffer I can transfer one line of text > with reasonable speed, but for many lines it's still a bit slow. I don't think we need to wory about performance at this stage. When you run another program in this way, you usually know that performance will suffer, since two programs are running simultaneously. I say make it work now and worry about performance later. > I think > I have to implement a callback function in the receiver that can be > called by the TSR (and hence by the sender). Such a mechanism could be translated to signals in the DJGPP programs. > Right now, the receiver > program has to poll all the time and look if there's something new in > the TSR's buffer. The sender, OTOH, has to wait until the receiver has > read the buffer. The sender has only to wait if there's no more space in the buffer. But you could have the TSR enlarge the buffer and make more space, so that the sender could continue writing its side, at least for a while.