I have committed on the CVS [1] the code needed for accessing simultaneous identical readers if their drivers support the new tag TAG_IFD_THREAD_SAFE.
If your driver is thread safe, please include this tag in the IFDHGetCapabilities. Return IFD_SUCCESS, *Length = 1, and *Value = 1.
This code is only for supporting simultaneous access to identical readers and NOT for the simultaneous access of different slots of a reader.
I hope it will work fine. I have testing it with the a "virtual IFDhandler/Reader" because I have only one thread-safe IFDHandler and also only one reader for it.
I wait the support of this feature by Omnikey for the Cardman 2020 or by someone for the CCID driver [1].
[1] https://alioth.debian.org/projects/pcsclite/
Regards,
Damien
David Corcoran wrote:
Hi,
I think it would be appropriate to support such methods now. A few years back most (all) of the smart card readers were serial in their operation. To have a multi-threaded resource manager that handles multiple slots (one per thread, no mutex) you really need hardware that allows you to send a command to it and then wait for an event as to when the command is completed. The problem is that in most readers, the reader itself is a serial device as in it can only execute one command at a time.
Is anyone on the list familiar with a reader that supports multiple slots that can be communicated with even while another another slot is under operation ???
Dave
On Thursday, September 4, 2003, at 04:47 AM, Michael Bender wrote:
Ludovic Rousseau wrote:
Le jeudi 04 septembre 2003 � 00:11:24, Michael Bender a �crit:
But why aren't drivers multi-threaded by default rather than playing a game with asking them if they are and then doing one thing if they say yes and another if they say no?
I don't know why the drivers are not multi-threaded by default. I was not yet in the MUSCLE community at that time. But I know most of them are _not_ multi-threaded. So we just can't decide to multi-thread pcscd and break a lot of drivers. Asking the driver is easy and backward compatible.
Yes, you're right about that, we went through the same thing in Solaris long ago when we had a bunch of non-MP-aware drivers that had to exist in the (new then) MP-enabled kernel. Unless the driver told the kernel that it was an MP-aware driver, the kernel assumed that it wasn't, and it grabbed a pretty heavy hammer lock on the system whenever it called into such a driver. It did take a while to flush out all the old non-MP drivers, and eventually I think all Solaris kernel drivers needed to be MP aware.
Maybe in a few years we'll be able to require all MUSCLE IFD handlers are MP/MT safe.
But it's just... I don't know, it seems that the UNIX community is fond of re-inventing and "re-discovering" old technologies every so often and marking them as "new" and "advanced" but only because the current crop of people have no history as to how things were done. MP/MT drivers are a good case in point, why weren't those drivers required to be MP/MT safe from day one? That's a rhetorical question of course.
mike
-- ----------------------------------------------------------------------- -----
Michael Bender E-Mail: [EMAIL PROTECTED]
Sun Microsystems, Inc. Tel: 831-401-9510
14 Network Circle Tel: x.31807
Menlo Park, Ca. 94025
Mailstop: UMPK14-260 MD: VPN/IMAP
By yourself you are nothing. It is only by relation to other living things that you achieve identity. Without the parent there is no child, without a lover you are not one either. Value living things. They are all you have become.
----------------------------------------------------------------------- -----
*********************************************************************** *****
SunNetwork 2003 Conference and Pavilion
"An unparalleled event in network computing! Make the net work for you!"
WHEN: September 16-18, 2003 WHERE: Moscone Center, San Francisco
For more information or to register for the conference, please visit:
http://www.sun.com/sunnetwork
*********************************************************************** *****
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscl e
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
