Ryan, no it's tested on commited version. And sorry for little confusing, I didn't get all informations correctly. LockAsync will end, but in that case (saf test, operations/SaLckLockGrantCallback/13.c) select will never get any information, so it just blocks.
Ryan O'Hara wrote: > On Tue, Jun 02, 2009 at 05:34:02PM +0200, Jan Friesse wrote: >> Included are lck service patches. Many of them solves really big >> problems (writing to uninitialized memory, testing some variable to >> NULL *BEFORE* it is used as a structure, ...) >> >> Ryan, >> it looks there is some huge problem with calling this sequention: >> [DEBUG]: saLckInitialize >> [DEBUG]: saLckResourceOpen >> [DEBUG]: saLckResourceLock >> [DEBUG]: saLckResourceLockAsync >> >> And lockAsync will never end. I didn't have time to figure our more >> deeply where is problem, so maybe you know, why it happend. > > Weird. I don't have that problem. Perhaps the tiny change I made to > the code in the patch I checked-int today resolved this? What exactly > do you mean by "lockAsync will never end"? Also, what type of lock are > the Lock and LockAsync calls requesting? I will try to reproduce. > >> Jan Friesse (7): >> Remove some warnings >> Sizeof should be structure and not pointer >> Test lockMode values >> Test resourceFlags in saResourceOpen(Async) >> Test validity of handle in *resourceLock(Async) >> Remove some compiler warnings. >> In saLckOptionCheck, test lckOptions to NULL >> >> trunk/include/ipc_lck.h | 2 +- >> trunk/lib/lck.c | 24 +++++++++++++++ >> trunk/services/lck.c | 75 >> ++++++++++++++++++++++++++++++---------------- >> 3 files changed, 74 insertions(+), 27 deletions(-) >> >> _______________________________________________ >> Openais mailing list >> [email protected] >> https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
