Mail Archives: djgpp/1998/04/20/16:50:22
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 -