Mail Archives: djgpp-workers/1998/01/15/12:31:52
On Thu, 15 Jan 1998, Anthony.Appleyard wrote:
> >> + cli /* disable interrupts */
> > I think this is both slow and unnecessary. Charles Sandmann agrees with
> > that, so I think this line should go away.
>
> If int (*_djgpp_kbd_callback)(int X) points to a user function, it will be
> called by the int09 hook routine and may take a while longer to run than the
> default routine alone.
The callback needs to be simple and fast, or else bad things will
happen. This should be explained in the docs, and then users should be
expected to know what they are doing (if they don't, they shouldn't be
messing with hardware interrupts in the first place). If their callback
is slow and non-reentrant, let *them* disable interrupts.
The problem with CLI is that some DPMI servers trap it and emulate it
with code that takes eons to execute. Is it worth it to punish all
potential users of this feature just because some will forget to do it in
their callback? For all I know, the CLI instruction itself could be the
reason for the reentrancy problem that you want to avoid, since it can be
so slow...
> > In this case, you haven't locked the code and the data, and it would surely
> > crash, since it is called from within an interrupt handler. (Neither did you
> > mention this in the description.)
>
> In my ventures so far into writing interrupt matter (using
> _go32_dpmi_allocate_real_mode_callback_retf and
> _go32_dpmi_chain_protected_mode_interrupt_vector), I got away without locking,
> probably because the areas of store involved were small and often used and
> thus DPMI likely happened to keep them always in RAM anyway.
No, that's because these two _go32_XXX functions lock the code and data
for you! But in your example, neither these nor any other means of
locking were not taken. At the very least you should have used the
_CRT0 flag that locks everything.
> > One thing which is definitely not right is that GCC assumes SS == DS, which
> > is incorrect in the interrupt handler, so the callback code should take care
> > of that also.
>
> I now save all possibe registers (segment and otherwise) before calling the
> user function and restore them afterwards. The software does not alter DS
> until after the user function has been called.
I'm not sure whether this solves the SS != DS problem. I think it
doesn't, since you don't set SS to DS as code produced by GCC assumes.
So if the callback references the stack, it will crash.
Somebody please check Anthony's code in this respect.
- Raw text -