[M3devel] chosing SIG_SUSPEND?

Jay jay.krell at cornell.edu
Fri Jan 23 08:09:40 CET 2009


I noticed in some of the code..I think for SegV, Quit,etc., not for thread suspension, that if the signalis already set to other than SIG_DFL, Modula-3 refrainsfrom changing it.
 
So, I was thinking, would it be reasonable to iterate through, saySIGUSR1, SIGUSR2, and SIGRTMIN through SIGRTMAX, anduse the "first" one that isn't set to SIG_DFL?By "first", I don't mean to imply what order to check in,probably my statement has the order backwards.The point is to check them and not just hijack them.
 
OR, is there another way to do this?
Doesn't or can't the Modula-3 code "check a flag""every so often" and then voluntarily yield?Of course, the allocator would check the flag.
Perhaps I just really need to get "that paper" into my head?Understand the issue around "other threads running intight computation loops for a long time", and therefore not checkingon yielding?
Is the signal mechanism actually preemptive anyway?
 - Jay> From: hosking at cs.purdue.edu> To: jay.krell at cornell.edu> Date: Wed, 21 Jan 2009 09:42:38 -0500> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] chosing SIG_SUSPEND?> > Yes, we want a signal no-one else is using to stop the threads.> > On 21 Jan 2009, at 08:37, Jay wrote:> > >> > Solaris at least currently has SIGRTMAX.> > I want to switch RTSignalC.c to "something" here.> > I can preserve compat, like> >> > #ifdef __sun> > SIGUSR2> > #else..> >> > or..?> >> > I could do> > #ifdef SIGUSR2> > #define SIG_SUSPEND SIGUSR2> > #elif defined(SIGRTMAX)> > #define SIG_SUSPEND SIGRTMAX> > #else> > #error> > #endif> >> > I'll go with a compatible version for now and you can change it if > > you want.> > I'll test on Linux/x86, FreeBSD (AMD64, but hopefully there is gcc - > > m32),> > Linux/PPC, Solaris, Cygwin, Darwin/PPC (uh, actually, no, Darwin isn't> > really relevant, but I'll make sure the result does what is intended.)> >> > It looks like SIGRTMAX is a function call on Solaris.> >> > This stuff is like broken, right?> > I mean, there's a small number of signals and there's no arbitration.> > People just take them over and hope nobody else cares.> >> >> > There's no way to just queue a function call to a thread, in > > portable/general?> > Windows has QueueUserAPC or SuspendThread (SuspendThread is dangerous,> > thread could be doing anything), QueueUserAPC only interrupts at > > certain times.> >> >> > - Jay> >> >> > ----------------------------------------> >> From: hosking at cs.purdue.edu> >> To: jay.krell at cornell.edu> >> Date: Wed, 21 Jan 2009 03:42:01 +1100> >> CC: m3devel at elegosoft.com> >> Subject: Re: [M3devel] chosing SIG_SUSPEND?> >>> >> Choose SIGRTMAX first if defined, then SIGUSR2. I don't thing NSIG-1> >> is reliable, but just works on some systems.> >>> >> On 21 Jan 2009, at 01:12, Jay wrote:> >>> >>>> >>> What is the algorithm for chosing SIG_SUSPEND?> >>>> >>> Something like:> >>>> >>> #include> >>>> >>> #ifdef __APPLE__> >>> /* nothing -- SIG_SUSPEND not used */> >>> #elif defined(NSIG)> >>> #define SIG_SUSPEND (NSIG - 1)> >>> #elif defined(_NSIG)> >>> #define SIG_SUSPEND (_NSIG - 1)> >>> #elif defined(SIGRTMAX)> >>> #define SIG_SUSPEND SIGRTMAX> >>> #else> >>> #define SIG_SUSPEND SIGUSR2> >>> #endif> >>>> >>> ?> >>>> >>> Whatever it is, I think it should be in RTSignalC.c.> >>>> >>> - Jay> >>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090123/17f1d2f3/attachment-0002.html>


More information about the M3devel mailing list