I read both posts, but I opted for a solution that required a change in one place rather than all over the place. It seems broken to me to put the burden of trying to predict the behavior of the kernel scheduler on the calling application. Application programmers should not have to "force a context switch" to get their applications to work as long as they are following established guidelines of thread-safe development.
If there is a problem that happens frequently and is due to problems at the kernel level, it seems like good defensive programming practice to add code in the library itself that will compensate for deficiencies in the scheduler. I admit, however, that this position is debatable and respect your difference of opinion. However, just because one person says that the current implementation is "perfect" doesn't mean it is. Regardless, I'm using libmusclepkcs11, so from my app's point of view, it is the library that is broken, not the app, only in this case we are talking about two different libraries. So the PKCS11 libraries should be updated to fix this problem. However, from my perspective It seems a lot easier to change one function that to change code in every place that calls that function. If you decide that I'm wrong, it would probably still be a good idea to document this problem so that people like myself don't spend hours trying to track it down. Thanks, Carl Youngblood On Mon, 19 Jul 2004 21:27:40 +0200, Damien Sauveron <[EMAIL PROTECTED]> wrote: > Hi Carl, > > Selon Carl Youngblood <[EMAIL PROTECTED]>: > > Thank you so much for that information. The patch that was posted > > solved my problem: > I think you have misread the thread! Patrick who had proposed this patch at the > beginning of the thread, had also concluded at the end that the current > implementation is perfect and thus it does not need to be patched. > > > FYI, I am running Fedora Core 2, which has the 2.6 kernel as was noted > > in the previous post. If this is not detrimental to others, perhaps > > this patch would be good to include in the libraries. > The problem is not at pcsc-lite level. The problem is at application level and > Patrick had proposed a solution in [1]: "By putting a usleep of 1 microsecond > after every SCardGetStatusChange, I can force a context switch and give a > chance to SCardTransmit to take the mutex." You can use a similar solution! > But please, the next time read carefully the posts. > > [1] http://archives.neohapsis.com/archives/dev/muscle/2004-q2/0240.html > > Regards, > > > -- > Damien Sauveron _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
