delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/09/28/19:56:33

Date: Sun, 28 Sep 1997 18:34:25 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Michael Mauch <michael DOT mauch AT gmx DOT de>
cc: djgpp AT delorie DOT com
Subject: Re: DJGPP, interprocess communication, and DPMI
In-Reply-To: <3432dbba.55370862@news.uni-duisburg.de>
Message-ID: <Pine.SUN.3.91.970928183400.423E-100000@is>
MIME-Version: 1.0

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019