Mail Archives: djgpp/1998/04/21/06:36:13
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.
> > 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...
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?)
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).
> 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.
- Raw text -