Re: [Vala] Setting up a GLib main loop with custom Sources with Vala 0.11.7

[Jim Peters <jim uazu net>]

Abderrahim Kitouni wrote:
> (See below for my attempts at improving your workarounds)

Thanks!  With your workarounds, I just need to make two patches to the
glib VAPI:

- Make SourceFuncs a struct (from a class)

- Add SIZE member to Source:

        public class Source {
                [CCode (cname="sizeof(GSource)")]
                public const int SIZE;

and then I can structure my Source subclass like this, and it all
works:

   private class ResizeHandler : Source {
      private static SourceFuncs resize_sf;
      private static bool prepare(Source src, out int timeout) { [...] }
      private static bool check(Source src) { [...] }
      private static bool dispatch(Source src, SourceFunc callback) { [...] }
      public ResizeHandler() {
         if (resize_sf.prepare == null) {
            resize_sf.prepare = prepare;
            resize_sf.check = check;
            resize_sf.dispatch = dispatch;
         }
         // Assume that ResizeHandler is the same size as Source
         base(resize_sf, Source.SIZE);
      }
   }


> > - Change SourcePrepareFunc in the VAPI to use 'int*' instead of 'out
> >   int' for the timeout, and change the calling code accordingly:
> >
> >         [CCode (has_target = false)]
> >         public delegate bool SourcePrepareFunc (Source source, int* timeout_);
> >
> >   This works around bug 645838.  Using 'out int' would be better in
> >   the long run.
>
> Another (better IMO) workaround is not to use a lambda expression and
> use a method instead.

Yes, that is better.


> > - Add a constructor for SourceFuncs in the VAPI, and implement
> >   g_source_funcs_new and g_source_funcs_free in C:
> > [...]
> >   Note that GLib expects SourceFuncs to be static data, i.e. it
> >   doesn't copy it or do any ownership stuff.  So the caller has to
> >   make sure it stays around as long as the Source remains active.
>
> That's not right, we can't have an additional C code other than what
> there is in glib. You can probably make it a struct instead: it will be
> allocated/freed automatically (as it is a value type), and could then be
> statically allocated.

Yes, changing to a 'struct' solves a whole load of problems.


> > - Pass a 'guessed' size value to the Source superclass constructor.
> >   The Source constructor wants to know the size of the object
> >   constructed.  The code 'sizeof(MySource)' gives the size of a
> >   pointer, not the size of the structure, so it doesn't seem possible
> >   to get this value in Vala.  So I pass 256 for now which is more than
> >   enough.
>
> A workaround I see here (but that would still be a hack), is to have a
> new constant named SIZE in GLib.Source defined as (untested):
>
>       [CCode (cname="sizeof(GSource)"]
>       public const int SIZE;
>
> and use that in the constructor (assuming you don't need additional
> fields in your source).

Yes, that does the job.  I will raise bugs so that the VAPI gets
fixed.

Thanks --

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                 jim uazu net
                          (_)  /=\  ~/_  (_)
 Uazú                  (_)    /=\    ~/_    (_)                http://
 in Peru            (_) ____ /=\ ____ ~/_ ____ (_)            uazu.net