Am 27.06.2010, 21:41 Uhr, schrieb Jo Even Skarstein <joska@online.no>:
Then it's select, which is ok. Next version will have longer entries for STATE.Does this mean that Taskbar itself is waiting in Fselect() (which it does at some points, but only to create some necessary delays using Fselect(millis, NULL, NULL, NULL)) or that XaAES is waiting on Taskbar's behalf?
It's most likely this: Fselect(millis, NULL, NULL, NULL), which should be ok. The fselect in XaAES is run by XaAES. But maybe replace this by usleep just for a test.
On my TT currently toswin has pid 13 and pgrp 1 (the one of XaAES). On aranym taskbar also has the pgrp of XaAES as all XaAES-clients have.The kernel and XaAES I'm using is yours from 11/6. Has things changed since then? Maybe a more recent version would help.
I use a current version on aranym and a quite outdated on the TT, so I don't think this would help. The pgrp of the clients is set in appl_init. Only when a client does not call appl_init or when it's not called directly by XaAES (maybe by a shell), the pgrp may be wrong.
What is the ppid of taskbar?
Taskbar does indeed wait for keyboard events. Disabling that does notUsing Bconin?No, plain AES events all the way.
That's no problem of course.
I most definitely have ;-) I will send you the current version later tonight.Ok - I wait for the third announcement ;)Hehe! It's not so easy when the Milan is not permanently online. But take a look in your mailbox now.
Arrived!
But I would first like to know why your pgrps are different.Me too.
I started it. Taskbar has XaAES-pgrp (as it should be), but I get your keyboard issue also. That's good news!
-- Helmut Karlowski