Older blog entries for Malkuse (starting at number 1)

An idea for LinuxThreads

The only reason I do my own scheduling in user space is because I need to control execution time slices. Thus, if there was a way to set the time slice for a LinuxThread, then I could just write a nice wrapper lib where MyThreads would be mapped one-on-one to LinuxThreads. And ofcourse figure out an efficient means to controll the slices with respect to process nesting hierarchies.
However, setting time slices for processes/threads is not possible with Linux. The time slice "belonging" to a process is just the side effect of the priority based scheduling mecanism. Some other path has to be explored.

Tadaa!
It is not currently possible for one thread to yield directly to another thread. I.e. a thread can only yield to the system, which will pick the next thread as it sees fit. However, yielding directly to another thread wouldn't really mess up anything if the scheduler was kept unaware of this "directed yield". Any time left of the slice would be used by the second thread, but the first one would still "pay" for it. Preemprion would work as if the first thread was still running. Such a yielding scheme could be used to do some really cool libs for process modelling :-)
Take a look at the report "CPU Inheritance Scheduling" released by the Fluke project. The idea is fleshed out pretty nicely there.

Possible trouble
Making a forced context switch a la setcontext(ucontext_t*) must somehow make sure that not only the NPC and SP + registers are switched. Threads do afterall have individual signal masks and so on. There seems to be an inherent conflict in doing a directed yield without bringing in system scheduling and at the same time making sure all parts of the new thread are activated properly.
It shouldn't be too bloody difficult though. It's my wild guess that there is something in the kernel which could aptly be called a "context switching atom". The scheduler utilizes this atom to go from kernel space into user space when the next-to-run process is chosen. If this atom was made usable from user space via a system call then any process/thread could yield its time to anyone who is known to need it better than the yielder. One could think of it as a way to safely managing CPU resources "better" than the system already does.

Considering the Towards the Anti-Mac article:

Radagast made a follow up and adressed ncm about a possible pseudo-english parsing shell. There is a fatal inherent flaw to such a shell, but it also made an old idea of mine resurface. Thus:

The Flaw
The name says it all: "pseudo-english". Obviously you'd want pseudo-german as well. Even considering a pseudo-japanese one is daunting to say the least. Porting such a shell to the different semantic structures (or tendencies towards such structures) of different natural languages is not practical.

The Remedy
Lets imagine some kind of scratchboard where you could mix representations of various acts (picked from tables divided according to the nature of the various tasks). Just like using redirection or variables in a shell script, the user would connect the representations using arrows. Thus forming a directed graph -- possibly a cyclic one with conditions for termination.
The acts would require the user to fill in parameters (in popups or whatever) just like a shell command does.
When a graph is constructed it could be saved as a new act, thus adding to the table of pickable acts.
Acts (or graphs of acts) could then be used as traditional scripts that the user executes manually or assigns to cron-like or event-driven agents. The acts could however also be used interactively by simply executing some act and adding subsequent ones as necessary. Backtracking would be possible since a session with history would exist naturally in form of the directed graph formed by the acts.
Finally, only the program managing the sets of acts (and the popups for various acts) would require translation between different natural languages. The acts themselves or the machinery underneath would require no knowledge of natural(-like) language to function.
The construction of original acts would still require skill in putting together shell scripts, but it wouldn't be a prerequisite for using existing ones.

How about that?

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!