Your bug fix is in my queue.
Alan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
On Mon, 22 Feb 1999, Bruce Evans wrote:
> >> spl is for blocking interrupts. Process-related things shouldn't be and
> >> mostly aren't touched by interrupts.
>
> >But without an spl, couldn't multiple processes do Very Bad Things in a
> >partially shared proc context?
>
> They can do that with
>> spl is for blocking interrupts. Process-related things shouldn't be and
>> mostly aren't touched by interrupts.
>But without an spl, couldn't multiple processes do Very Bad Things in a
>partially shared proc context?
They can do that with or without an spl if they don't lock things properly
s
On Sun, 21 Feb 1999, Bruce Evans wrote:
> >parts of proc (p_vmspace etc.) For that matter, does any of
> >kern_exit.c:exit1()
> >need to be spl()d? It sure seems like it to me. Along with other parts of
> >kern_exit.c, and many other things having to do with refcnt's. Is it just my
> >paranoia, o
>parts of proc (p_vmspace etc.) For that matter, does any of kern_exit.c:exit1()
>need to be spl()d? It sure seems like it to me. Along with other parts of
>kern_exit.c, and many other things having to do with refcnt's. Is it just my
>paranoia, or have I got this spl concept correct?
spl is for bl
Two things:
1. I've been looking at sysv_shm.c, and shouldn't there be a ton of splvm()ing
going on which isn't? It seems that there are quite a few race conditions
that never showed up before because there was no support for sharing certain
parts of proc (p_vmspace etc.) For that matter, does any
