--On Monday, February 02, 2009 07:52:30 PM +0200 Alon Bar-Lev <[email protected]> wrote:
> On Mon, Feb 2, 2009 at 7:41 PM, Jeffrey Hutzelman <[email protected]> wrote: >> --On Monday, February 02, 2009 04:28:22 PM +0200 Alon Bar-Lev >> <[email protected]> wrote: >> >>> The client library monitors /var/run/libscreader for changes >> >> That sounds really nonportable. >> > > I have it working for Linux (inotify) and BSD (kevent). > Solaris has FEM or something similar that use ports. > I am sure major arch has similar mechanism. > All other archs can poll or use some other system specific broadcast. > > The minimum required functionality is an event that be be triggered by > many processes, > and accepted by many clients without message lost. > > If you have a better idea, it would be great. > > I wish to avoid running application be connected to all reader processes > even if it does not use them, and still be able to detect reader > plugin/plugout and card plugin/plugout. The way to do this is to have a single service which provides a rendesvous point for clients and readers, keeps track of what readers exist and of their state, informs clients of changes they are interested in, and mediates when more than one client wishes to access the same reader. This is more reliable than depending on communicating via a filesystem whose state does not automatically change in exceptional circumstances such as when a reader process exits, more portable than depending on inotify, and more efficient than including copies of the server and mediation code in every reader driver and copies of the reader enumeration, selection, and monitoring code in every client application. -- Jeff _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
