A new event handling architecture

[salil_bhagurkar]

Okay, heres one really whacky ipc/event handling idea that i had. It is only suitable for kernel threads. It might involve some amount of overhead if this gets to the user mode. But as far as my os is concerned, i don't currently have any user mode and hence i found the implementation really nice and not slow as such.
Lets take a simple thread which is declared in the following fashion:

Code: Select all

int test_thread(void *args,unsigned long signal)
{
    //do work
}

Now in this function the 'signal' parameter which is passed by the scheduler to the thread upon creation is the new addition. This is where the thread receives the signal/event from other threads. Now it is possible for the thread to receive a signal on creation as well as at runtime.
The runtime part is the new idea. When a thread signals this test_thread, the scheduler simply adds one more thread to the system with the same entry point ('test_thread') passing the signal to it. This happens asynchronously even when the actual test_thread is running. The only difference as far as kernel threads are concerned is the stack that the new thread uses which is different from the thread that the actual test_thread is using. So to handle the signal we just have to write the following code:

Code: Select all

int test_thread(void *args,unsigned long signal)
{
    if(signal) {
        //handle the signal
        return 0;
    }
    //do work
}

Here the thread doesnt have to wait for events and get blocked. The new thread automatically handles the signal as and when required.

So how do you find this architecture?

[jal]

So how do you find this architecture?

Confusing, as I cannot see any use for it. How is this different from having two separate functions, one for the normal stuff and one for the signal?


JAL

[salil_bhagurkar]

Well, i see your point and in that point of view there is no such good advantage of this architecture. But having a separate function, you cannot have access to the local variables that the function under consideration is using.

[zerosum]

Neither can you in your method, because local variables are not only local to the function, they're in a sense, instance variables. They're stored on the stack, which will be different for each thread. The only way to avoid this would be to declare them as static, which is tantamount to a global, only it's declared in a more appropriate area.

-Lee

[salil_bhagurkar]

Okay, i realise the total uselessness of this method. It seems that i didn't give any considerable thought to my idea. Anyway i still have it in my os. It seems more interesting than the usual methods of event handling...
Atleast accept the innovation!

[karloathian]

Another problem I noted would be that you'd be handling events in sync , when certain events are not meant to be evaluated in sync.

For example , if a certain process was waiting on the user to press the shift key by setting a certain value , and would remove that value when the shift key is lifted. If for some reason the thread that got the "shift up" signal/message was called before the "shift down" signal/message then that the process would end up with that certain value set , when it actually shouldn't be.

PS. sorry if this doesn't make any sense, I'm really tired right now