Hi Oskar,
Hmm ... your examples work, indeed. Ours (using IPC) does not :-(
#include <l4/sys/ipc.h> #include <stdio.h>
int main(void) { while (1) { l4_threadid_t src; l4_umword_t dword0, dword1; l4_msgdope_t result;
// wait for IPC message until timeout reached if (l4_ipc_wait(&src, L4_IPC_SHORT_MSG, &dword0, &dword1, L4_IPC_TIMEOUT(0, 0, 1, 4, 0, 0), // wait for some time &result)) { dword0 = 0; } printf("%lu\n", dword0);
}
return 0; }
Are your user apps in the alien state? (Check with lp in jdb.)
26.00 a *.** 3s rcv,ipc_progr,alien
Seems so ... what does that mean?
`Alien' means that this task is special handled by the Fiasco kernel. In contrast to normal behaviour, L4 syscalls executed in the context of an alien task generate exceptions just before and after the L4 syscall. These exceptions allow the L4Linux server to set the internal Linux state of that task to "disk wait" to prevent that task from the Linux scheduling.
The above sample always blocks for exactly the IPC wait time. Then it runs again (accepting input, eg. from keyboard) and blocks again. It can be terminated by pressing CTRL-C as the input seems to be queued until the IPC wait timeout expired.
I cannot check this as I'm currently work with a different branch, but I would expect the exact behaviour as you describe. Or are _all_ Linux applications frozen while this task waits for an incoming IPC?
Frank