From: Damien Sauveron (sauveronlabri.fr)
Date: Fri May 07 2004 - 12:22:12 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Selon Valsecchi Patrick <patrick.valsecchinagra.com>:

> > I have the feeling that is a starvation problem in your
> > program and if you use 2
> > different contexts it will solve your problem.
>
> I write a smartcard adaptation layer to a closed source lib that does have
> multi threads. So it will be tough to have one context per thread.
Before the new clients management design, it was impossible to do that you want
to implement. All the requests were stood in a queue for all the contexts with a
global mutex. Also we have chosen to stand the requests in a queue for each
context
with a "context's mutex" and thus if you need to execute requests in parallel,
you need to have parallel contexts.
Note that the context release is only possible by the thread who creates it.

> > I have the feeling that your patch raise other problems. For
> > example if a
> > SCardTransmit call takes the hand just after the mutex unlock
> > of your patch we
> > don't know if this call spends 1 second or 1 min or 1 hour
> > and also we do not
> > guarante that the SCardGetStatusChange timeout after dwTimeout=1000.
>
> With the current implementation, you are far from being accurate. A usleep
> doesn't give you any warranty that it returns after the delay is elapsed. You
> may have another thread/process needing the CPU at that time. If you want to
> be accurate, you have to read the time (using gettimeofday in UNIX) before
> the loop and exit when you reached the target time (gettimeofday).
We use the nanosleep call in the SYS_USleep that is better than usleep in my
thought. But it is not the problem.

>The only problem I can immagine with my patch is if SCardTransmit is changing
> structures and the loop does some assumptions that this structure is not
> changed. But I didn't find anything dangerous after a quick glance.
The problem is that if SCardTransmit is called in the same context that the one
of the SCardGetStatusChange call, the SCardGetStatusChange execution will get
the hand only after the return of SCardTransmit. Indeed SCardTransmit is
protected by the "context mutex". Thus if the execution of SCardTransmit
requires 10 minutes, the execution of SCardGetStatusChange is suspended during
this time.
For information there are some cases where the cards work during a long time. I
work on a project [1] where our cards often work more than 10 minutes for an
APDU command.

If you have some comments or feedbacks about this design I will be interested.
Mainly, I wish to know if the microsoft implementation of PC/SC has a different
behaviour.

[1] http://damien.sauveron.free.fr/publications/CCCT03.pdf

Regards,
--
Damien Sauveron

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]