OSDev.org

The way this is implemented in Linux is by having multiple wait states. Normally system calls are pretty fast, so once you get a signal you just wait until you finish with a system call, and once it is done, you go and execute your signal handler. If you are waiting to acquire a critical section then you are in the uninterruptible state, and the incoming signals will be queued, but not processed until you release all your critical sections. However if the system call is expected to wait for a long time it enters an interruptible wait state, where it is expected that you will not be in any critical section. Once you are woken up from interruptible state the system call checks if there are any signals pending and if there are any, it exits out of the system call with either the current progress or EINT error code.

This mechanism although more complicated allows you to do actions like IO or terminate the process from inside the handler. The downside is that if your process is stuck in uninterruptible state there is no way to kill it, since SIGKILL will never be processed, and the only way is to reboot.

Actually, I've worked on this to possibly be able to add support for termination. Today, there is basically only two blocked kernel states: waiting for critical section (uninterruptable) and "waiting for signal" (usually interruptible). What needs to be done is to add functionality to all calls to "wait for signal" so they can be gracefully excited all the way back to user-land. That's only partially done. One possibility is to keep a special "terminated state" per thread, and check that when a "wait for signal" exists.

There is another requirement as well: All resources used by the application must be automatically freed whenever the application terminates for whatever reason. Again, the C-library cannot handle this as most of the resources are allocated by syscalls. This part of termination already works because the kernel keeps lists of used resources (kernel handles) per process. However, it doesn't work at the thread level, so if a single thread is terminated, the resources owned by the thread cannot be automatically freed. That's because RDOS assigns ownership of resources per process, not per thread.

Then there is the issue of terminating all threads before the application is terminated. That is also kind of complicated for multithreaded applications, and I presently have no solution for this. It more or less requires that threads can be terminated in some way.

Do I read this correctly - you haven't found a way to properly terminate threads, and therefore you didn't implement a means to terminate processes?

The whole idea of a self-service terminal is that the application never terminates, and if it terminates, it must be restarted (and then a reboot is far better than a restart of the application).

Your typical desktop user preferences are simply not valid for an embedded application, where nobody can interactively start or stop applications.

Yeah, well, whatever.

Would you mind explaining, then, how your posting about how you didn't implement process termination in your self-service terminal OS is topical in a thread discussing how somebody who wants to implement process termination could do so?

rdos wrote:Your typical desktop user preferences are simply not valid for an embedded application, where nobody can interactively start or stop applications.

That's a wide shot from the FUD you did spread with your first post in this thread:

rdos wrote:...too messy, and I hardly think it is possible to preempt operations in kernel and terminate the application. That could lead to kernel resources being locked forever.

I still don't know what your agenda is, but do stop assuming that everybody is aiming to re-implement RDOS.

Solar wrote:Do I read this correctly - you haven't found a way to properly terminate threads

They can terminate themselves, but you cannot force termination from the outside.

Solar wrote:and therefore you didn't implement a means to terminate processes?

Processes can also terminate themselves (provided there is only one running thread), but they cannot be force terminated from the outside. A well-behaved multithreaded application can also terminate provided the threads first are terminated, followed by an exist by the last thread. If this is not obeyed, a fault will occur, which in a production environment will trigger a reboot, which is exactly what is the most safe way of handling sudden termination in an unattended environment.

And so you take the opportunity to derail the thread further.

Please shut up.

If Solar cannot handle alternative solutions, I think he might better shut up. I certainly will not comment his last rant.

And my postings are relavant to the topic, while Solar's are not.

Combuster wrote:And so you take the opportunity to derail the thread further.

Please shut up.

You post is not relavant to the topic either, so you might just as well shut up as well.

But I suppose you two want this thread to be locked as well, but I won't help you any further as I won't comment anything more you two write here.

Hey, buddies, please stop throwing tirds to each other. It's very sad to see that non-civilized wars in a civilized forum. Try to avoid rude words and all will be OK then.

Meanwhile in the exciting world of OSDev...

Riveting.

EDIT: Gaiz, come on, let's stop all the needless violinz, kk? D:

I think that rdos reflections of the problems he faced with implementing this is valid. You simply do not agree with his conclusion to not support it at all, but in his OS - that seems valid too.
So why the mud-slinging? Do you really dispise his design decisions so much that you can't see beyond it? You may think every decision he ever took is totally wrong, but keep it to yourself - we have heard it before. I didn't look at his posts as a try to "convert" everybody to avoid implementing it, I viewed it as information on how and why this might be a hard thing to do.

Telling someone to shut up repeatedly (see other threads) is crossing the line IMO, and below any kind of standards that we should try and set for this forum.

Let's differentiate: I didn't "mud-sling".

But the question was:

thepowersgang wrote:Does anyone have suggestions on how this should (or could) be implemented?

That's what we talked about, rather constructively I might add.

Enter rdos.

He might have made a tongue-in-cheek comment how he had trouble with it and / or didn't need it in his OS, and leave it at that. I might even have replied along the lines of "oh the joys of embedded programming" or somesuch, and mean it.

But he went on at length how it's "too messy" (in his system), "I hardly think it is possible" (in his system), that it "could lead to kernel resources being locked forever" (in his system), that "a good way to stop an application" is a master reset (in his system) and that "the C-library cannot handle this as most of the resources are allocated by syscalls" (in his applications, I assume).

Note that he didn't put the qualifiers I did in the previous paragraph. That is confusing at best, misleading at worst, and overall hardly topical. Not implementing something is not an "alternative solution", especially not if the OP has pointed out he wants the functionality.

I pointed that out, a statement I do stand by, and took myself out of the thread.

Plonk.

Topic locked.

rdos, you started this - your post seems to be to be overly inflammatory and in "your usual style" - "XYZ is not possible" "ABC is difficult" without adding qualifiers saying you're referring to either your own implementation or lack of ingenuity.

You can hopefully see how this may get peoples' backs up.