Thread 'masking' into foreign processes

[Senaus]

This is an idea I had regarding kernel and user services; I don't know whether it already exists with a different name...

Basically, when a process makes a synchronous call to a service in another process (or the kernel), why not 'mask' the thread with new values instead of spawning a new thread to handle the request? This would allow the thread to keep its priority and access privileges whilst executing in a different context. Also, when the service is complete, it would simply return to a stub, which would 'pop' the old values back into the thread descriptor and return execution to the calling process.

What do you think?

Cheers,
The Senaus

[Pype.Clicker]

this technique is usually known as "thread tunnelling" or "thread migration", afaik. The main difficulty with it is to find a suitable stack in the "server" address space and to know what to do with datastructures that need to accompany the migrating thread between address spaces.

[Senaus]

The kernel (or the user-mode memory manager) would probably have to allocate a new stack for the thread, and as for the data structures, wouldn't the parameters to the foreign function suffice?

Thanks for putting the right name to it btw, now I can find some more information. Have you (or so you plan to) implement this in your kernel?

[JoeKayzA]

The kernel (or the user-mode memory manager) would probably have to allocate a new stack for the thread, and as for the data structures, wouldn't the parameters to the foreign function suffice?

When you have to allocate a new stack in the server address space, why not allocate a new thread? (or, better, get one off a pool of waiting threads). As for the parameters, what if one of them is a pointer to some large data structure (maybe even with more pointers inside)? You'd have to copy, or at least map, this structure too.

Have you (or so you plan to) implement this in your kernel?

I planned it once, for now I'm trying to find a good compromise between message-based RPC and thread tunneling - something like ipc with timeslice and priority inheritance.


cheers Joe

[Senaus]

When you have to allocate a new stack in the server address space, why not allocate a new thread? (or, better, get one off a pool of waiting threads).

IMO, the tunneling approach is much cleaner. The physical stack could remain the same - the kernel could simply remap it into server's address space.

As for the parameters, what if one of them is a pointer to some large data structure (maybe even with more pointers inside)? You'd have to copy, or at least map, this structure too.

As for pointers, the server would know which parameters are pointers, and it would be its responsibility to map this data into its own address space. This would be done by a call to the kernel; the kernel, seeing that the thread originated from that address space, would allow the server temporary access to the data. There may be security concerns with this - the kernel would have to restrict access only to certain parts of the address space otherwise a server could effectively hijack the calling process.

Cheers,
The Senaus

[JoeKayzA]

IMO, the tunneling approach is much cleaner. The physical stack could remain the same - the kernel could simply remap it into server's address space.

Yes, we discussed this quite extensively some time ago, whether it would be good to allocate a new stack or map the 'old' stack into the server address space. For myself, I didn't really come to a decision for several reasons:

• The kernel needs to allocate a free area of virtual memory in the server address space - and for my project, the kernel is not where the virtual memory allocator resides. So I would need a dedicated thread in the server context which gets magically notified to allocate a region for the new stack...(ok, these are probably problems with my design, not general ones)
• Even if you just map the whole stack over, it will most likely not get the same virtual base address as in the client's address space, meaning that pointers to other stack areas are rendered invalid. This was the main reason why I said it's not neccessary to keep the old stack, but to simply allocate a new stack and pass the parameters with some more advanced mechanism...

Please excuse me, but my expressions always seem to get a bit 'overcomplicated' when I start talking about technical detail...

cheers Joe