Skip to content
Snippets Groups Projects

krnl386, mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

Merged Alex Henrie requested to merge alexhenrie/wine:krnl386-callback-suspend into master
2 unresolved threads

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
    • This does refactoring that should probably be split off into other patches.

      I don't think it's right to pause whenever K32WOWCallback16Ex() is executed. Calling back from 32-bit code to 16-bit code isn't exclusive to hardware interrupts.

    • Author Developer

      Only one task can execute at a time anyway, so pausing the other threads usually won't have any effect. Are you saying that the functions that call WOWCallback16(Ex) should call TASK_SuspendAll and TASK_ResumeAll instead of calling them from within WOWCallback16Ex? Or are you proposing something else?

    • It works, but it's not declarative. I would think that whatever is doing hardware interrupts should be the place that's suspending win16 tasks.

    • Author Developer

      I can certainly export those two functions from krnl386 and then call them from mmsystem. Out of curiosity, what do you mean by "declarative" in this context?

    • Author Developer

      I've been thinking about this since yesterday and although we could make mmsystem call a __wine_suspend_all_tasks function or a __wine_wow_callback16 function that has an argument to specify whether to suspend other threads or to lock the Win16Mutex, it seems much less elegant. Here's why: If the callback is called from a task thread, it must be the current task thread because 16-bit Windows didn't have preëmptive multitasking, and TASK_SuspendAll has no effect. (We could even detect that case by checking whether the Win16Mutex is already locked by the current thread, and skip the call to TASK_SuspendAll if it is.) If the callback is called from a non-task thread, it must be a simulated hardware interrupt that needs to call TASK_SuspendAll. We don't have to change every function that might call WOWCallback16(Ex) from a different thread because WOWCallback16Ex can decide what to do based on whether it was called from the current task thread or from a different thread; it doesn't need any additional information.

      Does that make sense, or is there something I'm missing?

    • I can certainly export those two functions from krnl386 and then call them from mmsystem. Out of curiosity, what do you mean by "declarative" in this context?

      It's a difficult term to pin down, but somewhat abstractly, it means that code declares what should happen, not how, taking a top-down approach and putting logic where it belongs. More concretely, when some logic is conceptually conditional based on P, you want to check P in some way, rather than some unrelated or semi-related condition (or, in this case, no condition at all) that happens to be always the same as P in practice. This broadly makes code more readable, because it's communicating its intentions, and less fragile, because you don't have to remember the conditions that make P just happen to be true.

      In this case, we conceptually want to suspend the task when calling code from an interrupt. We are calling user mode code from an interrupt in specific places, so we should suspend interrupts in those places.

    • In this case, we conceptually want to suspend the task when calling code from an interrupt. We are calling user mode code from an interrupt in specific places, so we should suspend interrupts in those places.

      The bigger question is, do we actually need to do this? What bug is going to be fixed by suspending the tasks?

    • Author Developer

      The bigger question is, do we actually need to do this? What bug is going to be fixed by suspending the tasks?

      That would be Bug 56260. Fabian wrote a nice test program to demonstrate the essence of the problem.

    • That would be Bug 56260. Fabian wrote a nice test program to demonstrate the essence of the problem.

      I don't see anything in there that would require tasks to be suspended.

    • Author Developer

      Would you rather run the hardware interrupt callback in parallel with the current task, even though that would not have been possible on Windows? That would work fine for Myst, I was just concerned that it might break something else.

    • Please register or sign in to reply
  • Alex Henrie added 2 commits

    added 2 commits

    • 4c0d92fe - krnl386: Add functions to simulate a hardware interrupt.
    • a015693e - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alex Henrie changed title from krnl386: Pause other tasks while executing a callback. to krnl386, mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    changed title from krnl386: Pause other tasks while executing a callback. to krnl386, mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

  • Alex Henrie changed the description

    changed the description

  • Alex Henrie added 2 commits

    added 2 commits

    • ae9bdef8 - krnl386: Add a function to simulate a hardware interrupt.
    • 89e078c8 - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alex Henrie added 890 commits

    added 890 commits

    • 89e078c8...655de4b0 - 888 commits from branch wine:master
    • c1aeb393 - krnl386: Add a function to simulate a hardware interrupt.
    • f575642e - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alex Henrie added 1216 commits

    added 1216 commits

    • f575642e...6f2466ea - 1214 commits from branch wine:master
    • cf8980f7 - krnl386: Add a function to simulate a hardware interrupt.
    • 01c61067 - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alex Henrie added 745 commits

    added 745 commits

    • 01c61067...75f8de6b - 743 commits from branch wine:master
    • 26adb73d - krnl386: Add a function to simulate a hardware interrupt.
    • 2ca889f4 - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alex Henrie added 2732 commits

    added 2732 commits

    • 2ca889f4...a4604301 - 2730 commits from branch wine:master
    • d9e3a2a8 - krnl386: Add a function to simulate a hardware interrupt.
    • ce328f24 - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alex Henrie added 2 commits

    added 2 commits

    • fb83390d - krnl386: Add a WOWCallback16Ex flag to simulate a hardware interrupt.
    • dfc31e1a - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • added 43 commits

    • dfc31e1a...b7ca09bd - 41 commits from branch wine:master
    • e7b39642 - krnl386: Add a WOWCallback16Ex flag to simulate a hardware interrupt.
    • ff0fbb1f - mmsystem: Simulate a hardware interrupt in MMSYSTDRV_Callback3216.

    Compare with previous version

  • Alexandre Julliard approved this merge request

    approved this merge request

Please register or sign in to reply
Loading