Thanks for the additional references. That helps. I was also thinking: not only does the muscle PKCS11 library need to be updated to fix this problem, but the musclecard library does too.
I agree that the ideal thing would be to fix the scheduler, but there is often a wide gap between what is ideal and what is practical. For example, if I am developing a program for public consumption, I can't rely on the developers of my target platform to fix problems that I find in their libraries. Even if I could get them to fix the problems, people who had older versions of the libraries would not be unable to run my software and would be dissatisfied with my product. If it is within my power, it is in my best interest to code "defensively"--meaning that I should compensate for bugs in other layers whereever possible. You are the one who is most familiar with the code, so you know best where to update it and how to do it, but it is worth considering that a few small workarounds could alleviate a lot of problems for people who are using your libraries and increase the perception of value, even if you end up fixing other people's mistakes. In saying this, I recognize that I also need to follow my own advice and code defensively for problems that I might find in other layers. Thanks again for your time and attention. Carl On Mon, 19 Jul 2004 23:40:33 +0200, Damien Sauveron <[EMAIL PROTECTED]> wrote: > Carl, > > Selon Carl Youngblood <[EMAIL PROTECTED]>: > > I read both posts, but I opted for a solution that required a change > > in one place rather than all over the place. > Sorry for the bad assumption I have done. > > >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. > You are right on this point but if the Linux kernel has some problems it is not > our > work to solve it at pcsc-lite level. > > > 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. > No there are two persons (him and me) ;-) > And as I said at the end of [1] and at the end of [2] there would be some > problems with the patch proposed. Moreover I think that if the problem is in > the scheduler it is better to submit a patch/bug report to the kernel > developers. > > > 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. > Yes document this problem is good idea. We will do this. > > [1] http://archives.neohapsis.com/archives/dev/muscle/2004-q2/0219.html > [2] http://archives.neohapsis.com/archives/dev/muscle/2004-q2/0224.html > > > > Regards, > -- > Damien Sauveron _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
