[Mono-dev] [PATCH] mono-service bugs - please review
apenwarr at gmail.com
Wed Feb 6 10:43:43 EST 2008
Any comment on this one? Did I format the patch correctly?
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
> > > Or maybe it should always be true except when
> > > mono-service explicitly makes it false somehow?
> > This makes more sense.
> > 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,
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Mono-devel-list