> You could make em_find() take an argument to specify if it should acquire
> a WLOCK instead of an RLOCK.  Really, unless you have measured a lot of 
> contention on this lock, you should just make it a mtx, and only go back and 
> make it a rwlock if it really needs it.  Also, you currently can't do an 
> interlocked msleep() or cv_wait() with a rwlock, so you really need to use a 
> mutex anyway.
 
well... I rethink my design and I'll alter it to not use the rwlock at all.
I'll use per-emuldata mutex and there will be no SLIST of linux-thrads (I'll use
proc->p_emuldata to point at that)
 
> > anyway, I still dont understand how should I use the lock to achieve the 
> synchronization.
> > 
> > my code looks like:
> > 
> >     EMUL_RLOCK(&emul_lock);
> >             LIST_FOREACH_SAFE(em, &td_em->shared->threads, threads, tmp_em) 
> > {
> >     }
> >     EMUL_RUNLOCK(&emul_lock);
> > 
> > what do you suggest? I need to process the list first and then let the 
> exit_hook in the various processes run.
> 
> This is not safe anyway.  kill() is way too big of a function to call with a 
> lock held.  You also pass the wrong thread to it IIRC (you should always pass 
> curthread as the td argument to a syscall).  You probably need to use 
> psignal, and you probably should be doing something like this:
> 
>       EMUL_LOCK();
>       LIST_FOREACH(td, &td_em->shared->threads, threads) {
>               p = td->td_proc;
>               PROC_LOCK(p);
>               psignal(p, SIGKILL);
>               PROC_UNLOCK(p);
>       }
> 
>       while (THREADS_STILL_AROUND(&td->em))
>               msleep(td_em, &emul_lock, PWAIT, "foo", 0);
>       EMUL_UNLOCK();
> 
> Then in your exit_hook you should do this:
> 
>       em = em_find(p->p_pid, EMUL_UNLOCKED);
>       LIST_REMOVE(...);
>       SLIST_REMOVE(...);
>       wakeup(em);
>       EMUL_UNLOCK();


thnx! the psignal() is exactly what I wanted to know. but the original problem 
was that INVARIATNS
causes panic when LIST_FOREACH() {LIST_REMOV();}

I found a solution (I reference the data and free it in a separate step) to 
this so everything is nice
and smooth now :)

thnx!

roman
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to