Question about GC in C code.

Question about GC in C code.

[Jan D.]

Hello.

I have a question about how GC works in C.  My problem is this:

When a menu item is invoked in an Emacs built with a toolkit, a callback
is invoked.  That callback accesses an XVECTOR in the FRAME structure
(Lisp_Object menu_bar_vector) to find out what event to produce.
It is assumed that as long as the menus don't change, the XVECTOR
stays the same.  This is OK for toolkits used up till now.

In Gtk, a menu can be detached, appearing as a small window of its own.
But if the menus change in the frame where the detached menu originated
from, the XVECTOR is not vaild for the detached menu anymore.

So I made a small structure, like this:
  struct menu_gtk_data
  {
    FRAME_PTR f;
    Lisp_Object menu_bar_vector;
    int menu_bar_items_used;
    int ref_count;
  };

One such struct is malloc:ed and shared by all menu items.  When the menus
change, a new one is allocated.  So any detached menu still has access
to the old data.

But I confess that I have no clue as how GC works in the C code.
Will this approach work?  Will menu_bar_vector be safe from GC?
And when a struct menu_gtk_data is free:d, will menu_bar_vector
then be a candidate for GC?

I probably got this wrong, but how can I make this work?  An alternative
is to remove detachable menus of course.

	Jan D.

Re: Question about GC in C code.

[Richard Stallman]

    But I confess that I have no clue as how GC works in the C code.
    Will this approach work?  Will menu_bar_vector be safe from GC?

You have to modify the GC code in alloc.c to explicitly find these
C data structures in the menus and mark them the vectors by calling
mark_object.

    And when a struct menu_gtk_data is free:d, will menu_bar_vector
    then be a candidate for GC?

No, because the code you add to GC will not find it and mark it.

Is a detached menu a Lisp object?  If so, what data type is it?
Do we want a way to manipulate detached menus from Lisp?

Re: Question about GC in C code.

[Jan D.]

> 
>     But I confess that I have no clue as how GC works in the C code.
>     Will this approach work?  Will menu_bar_vector be safe from GC?
> 
> You have to modify the GC code in alloc.c to explicitly find these
> C data structures in the menus and mark them the vectors by calling
> mark_object.
> 
>     And when a struct menu_gtk_data is free:d, will menu_bar_vector
>     then be a candidate for GC?
> 
> No, because the code you add to GC will not find it and mark it.

Okay, thanks for the pointer.

> Is a detached menu a Lisp object?  If so, what data type is it?

It is more like a dialog popup window, or a file selection window.  It is
created by Gtk when you select a special menu item that looks like a dotted
line.  Gtk does all this detaching internally.

> Do we want a way to manipulate detached menus from Lisp?

I think not.  The idea is that it is to work exactly as a regular menu.
You get all the items in the File menu (for example) layed out in a separate
X window, so you can click on items in that window directly rather
that having to click on the menubar and then drag to the appropiate
menu item.  Its purpose is easier access to menu items.

The application using Gtk menus should not need to know if the selection
was made on a regular menu or a detached menu.

	Jan D.

Re: Question about GC in C code.

[Jan D.]

> 
>     But I confess that I have no clue as how GC works in the C code.
>     Will this approach work?  Will menu_bar_vector be safe from GC?
> 
> You have to modify the GC code in alloc.c to explicitly find these
> C data structures in the menus and mark them the vectors by calling
> mark_object.
> 

I think now I got it.  But instead of adding a Gtk-specific solution
I would like to propose a more generic variant.

How about if alloc.c was modified so other code could register a function
to be called when GC occurs?  That function could then mark lisp
objects as needed.  That way we can keep alloc.c free from knowing all
the details of data structures, and changes to those data structures
can be localized in just one file.  Something like this:

typedef void (*mark_function) (Lisp_Object *argptr);
typedef void (*gc_function) (mark_function func);

void
register_gc_function (gc_function func);

Then in the Gtk code I can do:

static void
mark_gtk_data (mark_function func)
{
  /* find menu data and mark */
  ...
  func(&data->menu_bar_vector);
  ...
}

...
  register_gc_function (mark_gtk_data);

The reason for mark_function is that mark_object is static in alloc.c, so
I pass it as an argument to gc_function.

Is this feasible?

	Jan D.

Re: Question about GC in C code.

[Stefan Monnier]

> How about if alloc.c was modified so other code could register a function
> to be called when GC occurs?  That function could then mark lisp
> objects as needed.  That way we can keep alloc.c free from knowing all
> the details of data structures, and changes to those data structures
> can be localized in just one file.  Something like this:

Usually what happens instead is that code tries to fit all the data it
needs to manipulate within a Lisp_Object data structure, so you don't
need any new mark routine, but you just need to register a few
more roots (if anything at all).

E.g. instead of using a C struct, you can use a Lisp vector.


	Stefan

Re: Question about GC in C code.

[Richard Stallman]

    How about if alloc.c was modified so other code could register a function
    to be called when GC occurs?  That function could then mark lisp
    objects as needed.

Would it really make a big difference?  I don't see it.  It would be a
simplification in something already simple, that is only done very
rarely.  Why do you think this would be a big improvement?

Re: Question about GC in C code.

[Jan D.]

> 
>     How about if alloc.c was modified so other code could register a function
>     to be called when GC occurs?  That function could then mark lisp
>     objects as needed.
> 
> Would it really make a big difference?  I don't see it.  It would be a
> simplification in something already simple, that is only done very
> rarely.  Why do you think this would be a big improvement?

The thing is I don't think I can guarantee that it will be rarely.
Since Gtk is new and some issues not really solved (tooltips in
menus, Gtk toolbar), I expect more Lisp_Objects may be needed in
Gtk callback data.  I would prefer to be able to make local changes
in a Gtk only file rather that propagate these changes into files
that really have nothing to do with GUI toolkits.

Also, I think minimizing the number of files that have to have
tests for USE_GTK is a good thing.

	Jan D.

Re: Question about GC in C code.

[Richard Stallman]

    The thing is I don't think I can guarantee that it will be rarely.
    Since Gtk is new and some issues not really solved (tooltips in
    menus, Gtk toolbar), I expect more Lisp_Objects may be needed in
    Gtk callback data.  I would prefer to be able to make local changes
    in a Gtk only file rather that propagate these changes into files
    that really have nothing to do with GUI toolkits.

You can add in GC a single call to a function in one of your files
and then add more code to that function as necessary.

Re: Question about GC in C code.

[Jan D.]

lördagen den 16 november 2002 kl 02.34 skrev Richard Stallman:

>     The thing is I don't think I can guarantee that it will be rarely.
>     Since Gtk is new and some issues not really solved (tooltips in
>     menus, Gtk toolbar), I expect more Lisp_Objects may be needed in
>     Gtk callback data.  I would prefer to be able to make local changes
>     in a Gtk only file rather that propagate these changes into files
>     that really have nothing to do with GUI toolkits.
>
> You can add in GC a single call to a function in one of your files
> and then add more code to that function as necessary.

That was the plan.  I can add one function call in GC, but it would still
be a GTK specific solution and make alloc.c dependent on USE_GTK.
Also, I imagine I have to declare this function in a .h-file, so
now alloc.c must also include and depend on that file.

I really prefer general solutions before specific ones to reduce
coupling.

	Jan D.

Re: Question about GC in C code.

[Richard Stallman]

    That was the plan.  I can add one function call in GC, but it would still
    be a GTK specific solution and make alloc.c dependent on USE_GTK.

That's ok.  It is not a big problem.

It is not worth constructing fancy mechanisms to solve an tiny
internal lack of elegance.  If it were big enough to cause real
hassles, then it might be worth some work to remove.