SoC: help with LISTs and killing procs
Divacky Roman
xdivac02 at stud.fit.vutbr.cz
Fri Aug 11 09:05:58 UTC 2006
> 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
More information about the freebsd-hackers
mailing list