Switching tasks suspends interrupts

[mrjbom]

Hi.
I have problems after my scheduler switches the task.
Using the task_switch(), the control is passed to the task01() function, the problem is that after the task01() ends, the control is not returned back(I expect the control to return to the pit_handler())
But this is not the main problem, the main oddity is that interrupts stop working when the task01() function is called, even though the interrupt flag is set. I have no guesses as to why task switching suspends interrupts.
What's going wrong?

[Octocontrabass]

You switch tasks before sending the EOI, so the PIC thinks you're still handling IRQ0, and won't allow another IRQ0 or any lower-priority IRQs to occur.

Since IRQ0 is the highest priority, there are no other IRQs that can occur.

[bzt]

You switch tasks before sending the EOI, so the PIC thinks you're still handling IRQ0, and won't allow another IRQ0 or any lower-priority IRQs to occur.

Since IRQ0 is the highest priority, there are no other IRQs that can occur.

I agree. The OP is missing a proper EOI.

Cheers,
bzt

[mrjbom]

Exactly, you're right.

But, how can I get the return statement in task01() to return control back to pit_handler()?

[Octocontrabass]

Set up the stack so the function will return to a function that performs the "end task" system call. The "end task" system call will remove the task from the queue, clean up (or enqueue deferred cleanup), and switch to another task in the queue.

One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().

You cannot return control to pit_handler() without another task switch.

[mrjbom]

Set up the stack so the function will return to a function that performs the "end task" system call. The "end task" system call will remove the task from the queue, clean up (or enqueue deferred cleanup), and switch to another task in the queue.

One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().

You cannot return control to pit_handler() without another task switch.

I realized that I think using system calls will be even more convenient.

The main difficulty will be that OS will need to monitor the presence of the system call "end_task ()" instead of return () in user programs, because if it is not there, the program will hang in the queue.

[iansjack]

When you compile programs for your OS you should include startup code that calls "main()" and, on return calls your end_task() (more usually called _exit()) system call. It would be poor design to require the programmer to insert the system call at the end of every program. Always let the compiler do any standard work rather than relying on the programmer.

[mrjbom]

When you compile programs for your OS you should include startup code that calls "main()" and, on return calls your end_task() (more usually called _exit()) system call. It would be poor design to require the programmer to insert the system call at the end of every program. Always let the compiler do any standard work rather than relying on the programmer.

I think I can get the compiler to insert "_exit()" instead of "return" in the required places so that the program ends correctly.

[nexos]

What happens is main() is called by the runtime. The runtime is the first code executed in an app, and it is a part libc. It calls global constructors, creates a heap, and calls main. main returns when execution is over and returns a value. It actually returns to the runtime. The runtime destroys its heap, calls global destructors, and lastly calls _exit() to exit the app/