[M3devel] modula3 fork and virtual timer

[Jay K]

Huh I'll check head later.
No I probably removed LTO sorry, but C backend...
Or maybe llvm?
Or report latest gcc?
LTO doesn't scale in compile time but Llvm has ThinLTO now..
LTO requires linker support. A matching linker? I'm not sure.

- Jay
________________________________
From: Peter McKinna <peter.mckinna at gmail.com>
Sent: Monday, August 14, 2017 6:21:15 PM
To: Jay K
Cc: m3devel
Subject: Re: [M3devel] modula3 fork and virtual timer

Hi Jay,

  I can't see that code anywhere in that file on git. What version are you using?

By the way, you wouldnt happen to know if we can get LTO support in the backend would you?

Regards Peter



On Tue, Aug 15, 2017 at 8:20 AM, Jay K <jayk123 at hotmail.com<mailto:jayk123 at hotmail.com>> wrote:

/mnt/d/dev2/cm3-5.8.6/m3-libs/libm3/src/os/POSIX/ProcessPosixCommon.m3


PROCEDURE Create_ForkExec:

.
.
.
    (* Turn off the interval timer (so it won't be running in child). *)

    nit := Utime.struct_itimerval {
             it_interval := Utime.struct_timeval {0, 0},
             it_value    := Utime.struct_timeval {0, 0}};
    IF Utime.setitimer(Utime.ITIMER_VIRTUAL, nit, oit) < 0 THEN
      <* ASSERT FALSE *>
    END;
 .
 .

 .

  fork()

 .
 .

    (* Enable scheduler. *)
    Scheduler.EnableSwitching ();

    (* Restore previous virtual timer. *)
    IF Utime.setitimer(Utime.ITIMER_VIRTUAL, oit, nit) < 0 THEN
      <* ASSERT FALSE *>
    END;


 This code has a number of problems.

 - It looks thread-unsafe -- another thread could be changing the timer.



 - The comments are wrong in multiple ways.
   The timer doesn't have to be turned off to not run in the child.
   Timers except alarm() are not inherited by child.
   It goes ahead and enables in the child anyway. Granted, after EnableSwitching,
   which also enables it!


 - Doesn't work on Microsoft's Windows Subsystem for Linux (WSL).

  You get back -1/EINVAL.


 - Is probably specific to user threads?



- Fails to put a useful message in the assert other than "FALSE"



Proposals:

 1. Remove it.
 2. Make it check for and ignore EINVAL, and possibly WSL, and not then enable in child.
 3. Change it to get in parent and set in child if enabled.

 4. Move it to Thread.AtFork in user threads. Though again, not clearly needed there.


 5. Consider that fork+exec should work from C/C++ code in a process that is using Modula3.


 6. Research posix_spawn and use it more.

 We can probably just use it and forget about any system that lacks it.

Thoughts?

 WSL can be detected by searching for "Microsoft" in /proc/sys/kernel/osrelease or /proc/version.


 Or we can just accept -1/EINVAL here for any OS.



 - Jay


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com<mailto:M3devel at elegosoft.com>
https://m3lists.elegosoft.com/mailman/listinfo/m3devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20170815/d88fd27c/attachment.html>