[Mono-dev] [PATCH] mono-service bugs - please review

[Avery Pennarun]

Hi guys,

Any comment on this one?  Did I format the patch correctly?

Thanks,

Avery


On 04/02/2008, Avery Pennarun <apenwarr at gmail.com> wrote:
> On Mon, Feb 04, 2008 at 02:12:48PM -0500, Jonathan Pryor wrote:
>
> > On Mon, 2008-02-04 at 12:14 -0500, Avery Pennarun wrote:
> > > 1. mono-service runner doesn't catch SIGINT (it should clean up like
> > > SIGTERM, and this is especially important when using the --debug
> > > option).
> >
> > Not as easy as you'd think; check the archives with the "Control-C
> > handler" subject.  To reliably catch SIGINT/SIGTERM/etc., you'll need to
> > use UnixSignal, which was just added to svn-HEAD.  If I'm lucky, I'll
> > get the tests written to permit it to go into 1.9 soon.
>
> I read that thread.  Luckily or unluckily, mono-service already catches
> various signals; SIGINT should be treated identically to SIGTERM, so making
> it work "better" should be a one-liner.
>
> Note that it currently is implemented by polling every 500ms, which is lame
> on multiple levels (you don't want daemons waking up every 500ms on your
> laptop for no reason, as it wastes power).  I eagerly await your signal
> patch.
>
> > >   Or maybe it should always be true except when
> > > mono-service explicitly makes it false somehow?
> >
> > This makes more sense.
>
> Implemented.
>
> > You can [DllImport("__Internal")] to obtain functions within the mono
> > executable, or (better) you can add an internal call to Mono that
> > mono-service would make use of.  Environment.UserInteractive could then
> > use a different internal call to obtain the value of some variable,
> > permitting communication (via internal calls) between mono-service and
> > System.Environment.  This is likely the best solution.
>
> I'm afraid I had a hard time deciding between the various methods here.  It
> didn't seem to me that an InternalCall was a very good choice, since we're
> just talking about a single bool and there's no reason that bool should be
> managed in native code.
>
> I did something else instead based on what was suggested elsewhere in this
> thread (private Environment.SetUserInteractive method that mono-service
> invokes via reflection).  I'm a little fuzzy on exactly what goes where for
> mono ABI compatibility, so please let me know if I've done it wrong.
>
> See the attached patch.  Changes:
>
> - mono-service makes Environment.UserInteractive false, otherwise defaults
>   to true.  (NOTE: this is the opposite of the old default!!)
>
> - mono-service can overwrite its lockfile if the lockfile isn't
>   lockf'ed.  This seems to be what was originally intended, but didn't
>   quite get implemented correctly.
>
> - SIGINT is now trapped and treated the same as SIGTERM, which is nice when
>   using the --debug option.
>
> Any chance this can go into the mono-1-9 branch?
>
> Have fun,
>
> Avery
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mono-service.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080206/7f5ed5ba/attachment.pl