Forum: Ruby-Gnome 2 Question about G_CHILD_ADD/G_CHILD_REMOVE

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Nikolai W. (Guest)
on 2009-03-26 20:40
(Received via mailing list)
Am I right in understanding that if you have code like

[GFile.new('a'), GFile.new('b').each do |file|
  file.read_async{ |contents| p contents }
end

will be fine even though #read_async is using code like

G_CHILD_ADD(mGLib, block);
...
G_CHILD_REMOVE(mGLib, block);

where block is generated by rb_block_proc()?  I mean, rb_block_proc()
gives me a new proc for each invocation that has a unique hash, right?

Sorry about all these questions that probably have pretty obvious
answers, but I'm really managing to confuse myself with this.
Kouhei S. (Guest)
on 2009-03-27 15:04
(Received via mailing list)
Hi,

In <removed_email_address@domain.invalid>
  "[ruby-gnome2-devel-en] Question about G_CHILD_ADD/G_CHILD_REMOVE" on
Thu, 26 Mar 2009 19:38:32 +0100,
  Nikolai W. <removed_email_address@domain.invalid> wrote:

> G_CHILD_REMOVE(mGLib, block);
>
> where block is generated by rb_block_proc()?  I mean, rb_block_proc()
> gives me a new proc for each invocation that has a unique hash, right?

Yes. But please use G_CHILD_* with an instance not
mGLib. It's enough that a callback block is associated with
just an instance. Lifetimes of a callback block and an
instance are same.


Thanks,
--
kou
Nikolai W. (Guest)
on 2009-03-27 16:00
(Received via mailing list)
On Fri, Mar 27, 2009 at 14:01, Kouhei S. <removed_email_address@domain.invalid> 
wrote:
>> end
> Yes. But please use G_CHILD_* with an instance not
> mGLib. It's enough that a callback block is associated with
> just an instance. Lifetimes of a callback block and an
> instance are same.

Yes, that was my initial thought as well.  However, doing that will
complicate the code quite a bit.  At the moment I simply pass the
block as the user_data to the async functions.  If I associate it with
self I'll have to pass in an allocated struct (or similar) containing
both self and the block, right?

Or can I do something like the following?

static void
read_async_callback(GObject *source, GAsyncResult *result, gpointer
data)
{
  VALUE block = (VALUE)data;
  â‹®
  if (NIL_P(block))
    return;

  G_CHILD_REMOVE(GOBJ2RVAL(source), block);
  rb_funcall(block, g_id_call, …);
}

static VALUE
read_async(int argc, VALUE *argv, VALUE self)
{
  â‹®
  VALUE block;
  â‹®
  rb_scan_args(argc, argv, "...&", ..., &block);
  if (!NIL_P(block))
    G_CHILD_ADD(self, block);
  â‹®
  g_file_read_async(_SELF(self), ..., read_async_callback, &block);
  â‹®
}

That is, will self and GOBJ2RVAL(source) be the same VALUE?  If I
understand GOBJ2RVAL correctly they won't.  Is there a way of getting
"self" in read_async_callback?

(I know that _SELF(self) and source are the same.)

Thanks.
This topic is locked and can not be replied to.