Page 1 of 1
thread switching and message sending
Posted: Mon Jun 09, 2014 8:46 pm
by seppe
The "create thread" call (f.51,1) seems to return immediately, returning a TID.
I assume that thread switching takes place during the next "wait event" (f.10) (and f.11?) when the event queue is empty.
1. Is this correct?
2. Can the slot number be obtained from a thread before the switch has taken place?
3. Is it possible to request the OS to switch to a windowless thread?
4. f72 allows to send message 2 and 3 to the active window. Can we send message 1 (redraw request)?
5. How to send a message to an inactive thread?
Re: thread switching and message sending
Posted: Mon Jun 09, 2014 11:50 pm
by Mario_r4
1) This issue requires further investigation. Earlier KolibriOS had a simple task manager - the threads switched around the ring. Subsequently, due to the need to implement USB stack, task manager has become more complex.
2) It is possible, but requires investigation. If I'm not mistaken, the creation of processes and threads are isolated by a pair of commands CLI / STI.
3) Windowless threads have equal rights with threads having a window. However, AFAIK, in kernel API does not have this feature.
4) This sub-function is not implemented in f.72. Generally any excess redrawing windows is useless waste of resources. The application should as little as possible call of f.1.
5) Today we have two possibilities:
5.1) Function 60 - Inter Process Communication (IPC)
5.2) Function 68, subfunction 22 - open named memory area
Function 68, subfunction 23 - close named memory area
If I am wrong, then let other developers will contribute their correction.
Re: thread switching and message sending
Posted: Wed Aug 13, 2014 5:14 pm
by CleverMouse
1. Partially. Thread switching can occur for two reasons: a) the current thread has nothing to do and decided to sleep, and b) the current thread is executing too long and the kernel has decided to give CPU to other thread. Waiting for event when event queue is empty is one of sleep functions, though not the only one, and goes to a). You can't control b) outside of kernel/drivers at all.
2. In general, no. Thread switching due to reason b) can occur at any time, including the moment just before returning from 51.1. If you are lucky, it is possible that it will never occur during development, but think about not-so-lucky users of your code.
For 3)4)5) I have nothing to add to the answer of Mario_r4.