task exit in microkernel environment...

[distantvoices]

... isn't fun at all. Ad maybe I am getting things wrong. How do you guys handle this issue?

I am doing it the following way:

at the beginning: eventually close present windows in the gui environment. close present pipes. continue.

1. send the MM-Server a message: Hey, I wanna quit!

2. MM-Server sends a message to system: remove the schedule-data(the kernel process structure) of this process.

3. system replies either whether the deletion is ok or not. any system processes shan't be removed. it also removes the process structure.

4. In case OK, mm-server sends a message to mm-driver (the paging daemon), which slips into the adress space of the process to delete and removes all the pages as well as the pagetables and the page directory. Message to mm-server: operation done/not done. - this part has to be fleshed out. It is very rough atm.

5.mm-server removes all memory related information about the deleted process from its lists.

6. for future: have the file system server remove all process related information (file handles especially, and flush data written by the process to disk)

that should do the job i think. It doesn't do. The keyboard becomes inoperable when quitting a process. Moving window boxes as well as the mouse (in gui environment) is present, but no one of the two remaining processes reacts to the keyboard. it is not a nice thing.

Well, let's see, how it continue, this special evolution. Forking off processes at will is operable. killing them is a problem at the moment, but that shall not hinder me.

Thank's for feedback

stay safe )

[Pype.Clicker]

woow. your kernel is building soo faaast :-p i kinda envy you ;D

well, killing a task is for sure not a trivial issue. Do you have hints on the operation that breaks everything ? For instance, what does occur when you just remove the threads (i mean, *all* of them) of the process from the scheduler's queue ?

Would you by any chance have threads waiting on some resources that have a 'pending threads' counter ? if so, you should resume safely the state of the object while the thread get killed ...

Would you also have threads that were holding semaphores or things like these ? in that case, killing the thread should either be deferred until no resource is held or the semaphore should be released (but chances are that you're not willing this).

In Clicker, i have used 2 'tricks' to make threads/process deletion possible:
1. i have an omnipresent system thread that can move accross address space at will in order to perform requested operations. One of these operation is go to an address space and kill every runnable thing in it, then terminate every memory object present (will be extended to every resource the process holds later) and move back to the 'system' address space to release the page directory. As the OST is fully contained in the microkernel, it is much easier to clear things like stacks, etc. from there. Only the page directory requires special attention.
Also, as my OST is unique (i.e. Singleton pattern), it makes less synchronization problems (noone else can be trying to kill threads).

2. Each thread has a 'shield' counter, which can be incremented when the thread is not willing to be killed. shield() and unshield() operations should always pair, and the thread should be shielded when it cannot be killed safely (for instance if it's operating on something protected by a semaphore). When someone attemps to kill a shielded thread, the thread get the 'SHOT' flag (or smthg alike) and it will die when its shield level will get back to 0.

Hope it helps.

[distantvoices]

Och, you are kidding. *rofl*

BlueIllusion is rough as a bag of old rags and it stinks of dirty hacks like old fish to be honest. Even the gui environment is shabby and fishy - only text console controls available, no loopers for catching mouse events and so on.

ONly a few days ago, I've cleaned up my video driver - removed all that code from the main loop into functions - looks more professional and less shabby.

re Operation that breaks: No, not yet any hints on that.
But I think it has to do with my manner of how to fetch data from the keyboard driver.

thanks for your Hints, I'll take them into consideration.

PS: your Kernel evolves in a really organized fashion. THe more: it runs. *not away, thats for sure*

[distantvoices]

Got it, that weird thing. Some ugly bug in my double linked list management for the processes it's been, which caused it loop around in the circular linked list. But no problem. I've got still the alternative working: the process table - unfortunately limited size, but this is nothing worth making a big fuzz about. Once I've done considerate debugging with this linked list code, I'll remuve that static stuff and from then, the processes are managed in a dynamically allocated table.

The more, there's been some weird bug in the communications protocol which caused the whole system to crap out with out any further boo. (the kernel made a boo...)

stay safe...