Re: Changes to calendar objects reg. alarms.

[Miguel de Icaza <miguel gnu org>]

> Problem 1: The gnomcal conduit calls calendar_string_from_object (to
> update gnomecal objects) which calls calendar_new. Thus the gpilotd has
> effectvely now called setitimer, thereby causing SIGALRM's whenever
> (todays?) gnomecal events have their alarm set.

This is very strange Eskil.  Because, the GnomeCal is not running into
the same address space as the conduit is, right?

So the setitimer call happens in the "gnomecal" executable, *not* in
the gpilotd executable.

> Solution 1: let gpilotd register a handler for sigalrm.
> Bad, since 1) it is a hack 2) it does not solve problem two,
> which is a generic gnomecal problem 3) pilot-link uses sigalrm for serial
> port watchdogging. Since problem two is not resolved, this is Not Good.

I do not understand why the SIGALARM in gnomecal affects gpilotd at
all.

> Solution 2: alter calendar_new to _not_ call init_alarms.
> Since programs that want to alarms generated can call
> calendar_init_alarms. This means the major calendar object in gnomecal can
> call calendar_init_alarm itself (gnome-cal.c(gnome_calendar_new)).

Sounds fine to me.

> I lean towards solution 2, as it preserves the interface, and lets
> the individual program choose to enable alarms.

Yep.

miguel.