Hi, I agree with the arguments of Michael. I understand the position explained by Jean-Luc and I thank also that PC/SC Lite puts a lock on a call until the return of this call. But if someone develops a ifdhandler supporting multiple reader instances, it seems obvious to design it for supporting multi-threading. IMHO, the solution proposed by Ludovic is perhaps the least bad solution but it is not very nice for the PC/SC Lite behaviour and design. I will prefer a solution where all drivers will be threadsafe. I hope that we have quickly a solution for this problem, because I want use PC/SC Lite in the same way as Bettina, but for doing distributed computing on smart card.
Regards, Damien Sauveron Michael Bender wrote: > Ludovic Rousseau wrote: > > Le mercredi 03 septembre 2003 à 20:03:19, Jean-Luc Giraud a écrit: > > > >>Hi, > >> > >>What you see is probably is due to how pcscd handles multi threading. I > >>might be wrong, but I think that pcscd acquires a lock for each call to > >>a specific driver and only realeases it once the call is finished. > >>Calls to a specific driver are therefore serialised. This has the great > >>advantage of making the development of drivers much simpler (you don't > >>have to worry about mutlithreading in the driver). The dawback is that > >>the driver can only execute one command at a time. > > > > I think you are right. > > > > The easiest way would be to ask the driver using IFDHGetCapabilities() > > and a new tag to see if it can be multi threaded safely or not. > > 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? > > Unless there is some common resource that a multi-slot driver needs > to access, there is reall yno reason why a multi-slot driver can't > be thread safe nor why there should be a "single slot version" and > a "multi slot version" of the same driver. And, if there is a > common resource that a driver needs to share among it's slot > instances, there are well-defined mechanisms for doing that > (mutexes and rw locks to name two). > > This thread stuff is all basic computer programming 101 and it's > been around for at least a few decades, so I'm not sure why it > always seems that everyone in the Linux community always gets > so bent out of shape when the issue of threading comes up. > > 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 > > Never give up! Never surrender! > > ---------------------------------------------------------------------------- > > **************************************************************************** > > 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 > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
