Re: Fast user switching notifications
Thank you very much for your reply. It was really helpful. Jean There is an other way to track the current user: using the SystemConfiguration framework notification: http://developer.apple.com/library/mac/#qa/qa1133/_index.html -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Fast user switching notifications
Le 11 mars 2013 à 23:25, Jean Suisse jean.li...@gmail.com a écrit : Dear All, There may be several approaches to solve the issue I am about to describe, either on the userland side or on the kernel side... or in-between, using a daemon. Current situation A bsd kernel extension communicates with a regular userland application (called theApp). The kext gathers statistics, sends data to the user, takes orders from the user, etc.. There are two-way communications initiated by both sides using control sockets – There may be no market for such app, it is more of investigation tool, but that's irrelevant. Goal I would need to handle fast user switching, so that data sent by the kext are directed towards the user that can actually handle them. This user is the one owning the graphic interface (is there a technical word to say that?). Issue When switching from user(A) to user(B) (using fast user switching for instance), user(A) no longer owns the graphic interface and theApp(A) is no longer able to interact with the user and give the required feedback to the kext. User(B) starts theApp(B) and interacts normally with the kext. Then, when switching from B to A, the same issue occurs in reverse. Solution One approach would be to have theApp(A) launched by user(A) to be notified when user(A) looses access to the graphic interface. When switching back to user(A) theApp(A) and theApp(B) would also get notified. I read this document (https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPMultipleUsers/Concepts/UserSwitchNotifications.html), but it seems that there is some race condition occurring, maybe as a result of interacting with the kernel (the kext must perform a few tasks before allowing theApp(A) to disconnect and theApp(B) to connect). Are there any other alternatives, from the userland side ? There is an other way to track the current user: using the SystemConfiguration framework notification: http://developer.apple.com/library/mac/#qa/qa1133/_index.html -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Fast user switching notifications
Dear All, There may be several approaches to solve the issue I am about to describe, either on the userland side or on the kernel side... or in-between, using a daemon. Current situation A bsd kernel extension communicates with a regular userland application (called theApp). The kext gathers statistics, sends data to the user, takes orders from the user, etc.. There are two-way communications initiated by both sides using control sockets – There may be no market for such app, it is more of investigation tool, but that's irrelevant. Goal I would need to handle fast user switching, so that data sent by the kext are directed towards the user that can actually handle them. This user is the one owning the graphic interface (is there a technical word to say that?). Issue When switching from user(A) to user(B) (using fast user switching for instance), user(A) no longer owns the graphic interface and theApp(A) is no longer able to interact with the user and give the required feedback to the kext. User(B) starts theApp(B) and interacts normally with the kext. Then, when switching from B to A, the same issue occurs in reverse. Solution One approach would be to have theApp(A) launched by user(A) to be notified when user(A) looses access to the graphic interface. When switching back to user(A) theApp(A) and theApp(B) would also get notified. I read this document (https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPMultipleUsers/Concepts/UserSwitchNotifications.html), but it seems that there is some race condition occurring, maybe as a result of interacting with the kernel (the kext must perform a few tasks before allowing theApp(A) to disconnect and theApp(B) to connect). Are there any other alternatives, from the userland side ? Jean ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
