Message-ID: <3548A39B.6CE0@CGSTE.MQ>
Date: Thu, 30 Apr 1998 11:15:23 -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 980421133407 DOT 1009I-100000 AT is>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk

Eli Zaretskii wrote:
> 
> On Mon, 20 Apr 1998, HANRIGOU Philippe wrote:
> 
> > If I comment this __dpmi_yield, bash still freezes (Didn't take time to
> > figure out where, because I suspected others __dpmi_yield calls).
> 
> Please see if the other place where it freezes is indeed another call
> to __dpmi_yield.
> 
I've seen that for you: bash definitely freezes at another call to
__dpmi_yield.

> > > 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).
> 
> Please try to see if this indeed works.  My references indicate that
> if no screen output is done between two calls to __dpmi_yield, the
> virtual machine will sometimes be stopped for prolonged periods of
> time.  (Btw, did you try to leave Bash in the ``frozen'' state for a
> long time and see if it awakens eventually?)
> 
I've left Bash "alone" in a frozen state for hours (more precisely 3
hours) without
any "resurection".

> To ease the pains of testing the changes with how __dpmi_yield is
> called, you might try writing your own __dpmi_yield that outputs
> something to screen then calls the function to yield the time slice.
> This might make it easier to test if this helps (you don't need to
> track down all the calls to __dpmi_yield and change them).
> 
I've just add these lines at 'tminit.c' begining:

#ifdef __DPMI_YIELD_BUG
  #define __dpmi_yield()							\
  do {										\
  	fprintf(stderr, "__dpmi_yield: about to call\n");			\
	fflush(stderr);								\
	__direct_outputs(" \b");						\
	__dpmi_yield();								\
	__direct_outputs(" \b");						\
  	fprintf(stderr, "__dpmi_yield: back\n");				\
	fflush(stderr);								\
  } while(0);
#endif /* __DPMI_YIELD_BUG */

And I compiled tminit setting -D__DPMI_YIELD_BUG. Unfortunately, screen
output
does not repair the bug. Everything's the same (freezing on a
__dpmi_yield call)! 

> > 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?
> 
> It is not nice for a program to eat up CPU cycles when all it does is
> to wait for the user to type something.  I would like to try solving
> this problem without removing __dpmi_yield calls.
Ok, said like that, I can't but agree with you. I just hope you'll find
the clue!

-- 
_______________________________________________________________________
  
     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
_______________________________________________________________________