[M3devel] awful race condition in libm3/FilePosix.m3?

[Jay K]

I commited a fix. But two questions:

1) why not just stat, instead of open, fstat, close?

2) a lighter weight way to fix this than I did?
In particular:
a) VAR m := NEW(MUTEX);
can we at least say VAR m: MUTEX instead? I tried. It crashed.

b) some notion of a "once"? a lock that will only be successfully entered once, for one-time initialization, all other attempts to enter wait for the first enterer to leave, and the it is never entered again. pthreads has this. Win32 since Vista has it (I'd still provide something compatible to pre-Vista, but it can be done easily enough.
They are faster and perhaps smaller than other kinds of locks.

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Wed, 30 Jan 2013 07:40:02 +0000
Subject: [M3devel] awful race condition in libm3/FilePosix.m3?




FilePosix.m3:


I'm not 100% sure, but looks really bad.
I suspect it will close arbitrary files out from other threads.
Notice there is absolutely no mutual exclusion.
An arbitrary number of threads will run here, mostly succeeding, but not necessarily.

VAR
  null_done := FALSE;
  null_stat: Ustat.struct_stat;
  null_fd: INTEGER;


PROCEDURE IsDevNull(READONLY statbuf: Ustat.struct_stat): BOOLEAN RAISES {} =
  VAR result: INTEGER;
  BEGIN
    IF NOT null_done THEN
      null_fd := Unix.open(M3toC.FlatTtoS("/dev/null"), Unix.O_RDONLY, Unix.Mrwrwrw);
      IF null_fd < 0 THEN
        null_done := TRUE;
        RETURN FALSE
      ELSE
        result := Ustat.fstat(null_fd, ADR(null_stat));
        EVAL Unix.close(null_fd);
        IF result # 0 THEN
          null_fd := -1
        END
      END;
      null_done := TRUE;
    END;
    RETURN null_fd >= 0 AND statbuf.st_rdev = null_stat.st_rdev
  END IsDevNull;


 - Jay
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130130/18dcd12f/attachment-0002.html>