Message-ID:	<353BC147.53FA@CGSTE.MQ>
Date:	Mon, 20 Apr 1998 16:42:31 -0500
From:	HANRIGOU Philippe <HANRIGOU AT cgste DOT mq>
Reply-To:	HANRIGOU AT cgste DOT mq
Organization:	CONSEIL GENERAL DE LA MARTINIQUE / DGA2
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	DJGPP <djgpp AT delorie DOT com>
Subject:	Re: Problem with bash
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980419141654 DOT 23362M-100000 AT is>

Eli Zaretskii wrote:
> Okay, here's a few things I'd suggest to try:
> 
> First, make sure it's really __dpmi_yield that gets you.  Just comment
> the call to it out, rebuild Bash and see if the problem goes away.
> 

I've modified the __libc_termios_read_cooked_tty function like that:
("++" at line begining indicates added lines)

static ssize_t
__libc_termios_read_cooked_tty (int handle, void *buffer, size_t count)
{
  unsigned char *wp;
  ssize_t n;

  wp = buffer;
  n = count;

+++ trace("__libc_termios_read_cooked_tty: Begins, handle=%d count=%d",
+++       handle, count
+++ );

#if 0
  /* clear cooked queue */
  if (__libc_termios_exist_queue ())
    __libc_termios_clear_queue ();
#endif

  if (__libc_tty_p->t_lflag & ICANON)
    {
      /* get inputs (wait for NL or EOT) */
      if (! __libc_termios_exist_queue ())
	__libc_termios_fill_queue ();

      while (--n >= 0)
	{
	  if (! __libc_termios_exist_queue ())
	    break;

	  *wp++ = __libc_termios_get_queue ();
	}
    }
  else
    {
      /* block until getting inputs */
      while (! __libc_termios_exist_queue ())
	{
+++       trace("__libc_termios_read_cooked_tty: Call __dpmi_yield");
	  __dpmi_yield ();
+++       trace("__libc_termios_read_cooked_tty: Back from 
__dpmi_yield");
	  __libc_termios_fill_queue ();
	}

      while (--n >= 0)
	{
	  *wp++ = __libc_termios_get_queue ();

	  if (! __libc_termios_exist_queue ())
	    {
	      __libc_termios_fill_queue ();
	      if (! __libc_termios_exist_queue ())
		break;
	    }
	}
    }

+++ trace("__libc_termios_read_cooked_tty: End, result is %d",
+++       (ssize_t) (wp - (unsigned char *) buffer)
+++ );
  return (ssize_t) (wp - (unsigned char *) buffer);
}

Where "trace" is the function from "error.c". Below are the last lines
of the
trace file ("classic ls freezing session").

---------------------- Last lines of trace file -----------------------
[stripped]
TRACE: pid 6121: __libc_termios_read_cooked_tty: Call __dpmi_yield
TRACE: pid 6121: __libc_termios_read_cooked_tty: Back from  __dpmi_yield
TRACE: pid 6121: __libc_termios_read_cooked_tty: Call __dpmi_yield
TRACE: pid 6121: __libc_termios_read_cooked_tty: Back from  __dpmi_yield
TRACE: pid 6121: __libc_termios_read_cooked_tty: End, result is 1
TRACE: pid 6121: __libc_termios_read_cooked_tty: Begins, handle=0
count=1
TRACE: pid 6121: __libc_termios_read_cooked_tty: Call __dpmi_yield

------------------------- End of trace file ---------------------------

So it really seems that bash never come back from last __dpmi_yield. 
If I comment this __dpmi_yield, bash still freezes (Didn't take time to
figure
out where, because I suspected others __dpmi_yield calls). But If I
comment
every __dpmi_yield call in tminit.c: EVERYTHING SEEMS OK (I ran a few
djgpp 
commands without any trouble).

> If __dpmi_yield *is* the problem, please look at the property sheets
> of your DOS box, in the "Misc" tab, and tell what are your settings
> there. 
I've got a french version of Windows 95. I've tried to translate these
property 
sheets, but it's not sure that it correspond exactly to what's written
in your 
"Misc tab":

[Foreground]
   Allow screen saver = yes

[Mouse]
   Quick edit = no
   Exclusive mode = no

[Background]
   Suspend always = no

[Stop]
   Alert if still active = yes

[Idle Sensitivity]
   Sensitivity = medium

[Others]
   Fast paste = no

[Windows shortcuts]
   everything checked...

> Next, try playing with the "Idle Sensitivity" setting and see
> if that helps (mine is set to the lowest sensitivity).  You will need
> to restart the DOS box after every change.
> 
I set Idle sensitivity to the lowest one: doesn't work (If I keep
 __dpmi_yield calls of course).

> Also, see whether your %windir%/system.ini file has an
> IdleVMWakeUpTime setting somewhere.  If it does, please tell what does
> it say.
> 
It hasn't got any.

> If nothing above seems to help or provide any clues, one other thing
> to try would be to insert some code which will cause some screen
> output inside the loop which calls __dpmi_yield.  For example, you
> could insert a call to __direct_outputs which prints a string " \b".
> This will leave no visible trace on the screen.  It might be that
> writing to the screen repairs the bug without having the adverse
> effects of not calling __dpmi_yield (programs which idle should not
> eat up CPU time).
> 
Still interesting? I haven't slept too much this night and I feel a bit
lazy. Tell me whether it still helps...

> I don't think you need to plunge into DPMI specifics for this
> problem.  The name __dpmi_yield suggests that this is a DPMI function,
> but it really isn't.
Ok. You said that __dpmi_yield just yields the rest of the current time
slice so other programs get CPU control. So, what is the problem if I
use
a bash with all __dpmi_yield calls commented? I guess, I'll have a
monotask behaviour of bash as opposed to others applications, but will
I have a good multitasking emulation for commands launched from bash
(background jobs facilities, etc.)?

Thanks you very much for all your help,
Regards,
Philippe.
_______________________________________________________________________
  
     Philippe HANRIGOU           Conseil Général de la Martinique
  Ingénieur informatique              D.D.S.T. - service I.T.S.
                                Immeuble Concorde, route de la Folie
   Tél: (0596) 59-84-63                  97200 Fort de France
  E-mail: HANRIGOU AT cgste DOT mq                      FRANCE
_______________________________________________________________________

- Raw text -