> What is that proc bug? I search bug-hurd and i only found a patch from Neal
> that adds /* XXX race condition */ comment but i didn't investigate further.
That was bogus (at that point, I did not realive that there could be no
race conditions as proc is single threaded). This was corrected in
On Tue, Jun 05, 2001 at 11:14:11PM -0700, Jeff Bailey wrote:
> The proc bug exhibits only under heavy load. I've never looked at the
> internals, so I don't know if these arrays could be the cause of the
> crash but I will cheerfully test it if you send me the patch. I some
> have easily reprodu
On Wed, Jun 06, 2001 at 08:30:32AM +0300, Ognyan Kulev wrote:
> In $HURDSRC/proc/host.c, function S_proc_setexecdata uses std_port_array and
> std_int_array without exclusive lock. This can lead to a kind of corruption
> if two threads call this function simultaneously (race condition)
proc is effectively single-threaded, see proc/main.c:message_demuxer.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Hi,
In $HURDSRC/proc/host.c, function S_proc_setexecdata uses std_port_array and
std_int_array without exclusive lock. This can lead to a kind of corruption
if two threads call this function simultaneously (race condition). I know
that this is almost impossible to happen, but i'm asking
