Re: more mainloops in more threads?
- From: Paul Davis <paul linuxaudiosystems com>
- To: Roberto -MadBob- Guido <bob4mail gmail com>
- Cc: gtk-list gnome org
- Subject: Re: more mainloops in more threads?
- Date: Tue, 01 Apr 2008 19:16:12 -0400
On Tue, 2008-04-01 at 23:17 +0200, Roberto -MadBob- Guido wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 01 April 2008 22:39:15 Paul Davis wrote:
> > it might help to realize that signals are nothing more (or less) than a
> > way to execute a list of closures
> >
> Exactly as I was afraid to be.
>
> So, adding a signal connection adds an item into that (unique for all the
> application) list, increasing time to lookup and traversing. Right?
Wrong. The list of closures is attached to that *signal*, which in turn
is a property of the object that emits it.
> And, as I can understand, there is no way to manage different lists of
> handlers for different contexts (say: for different threads).
as chris pointed out, your new understanding is wrong ...
> I think Glib will need some low level revisions to match requirements for near
> future computation models...
i think i would advise reading a bit more and thinking about some of the
projects that already exist and their likely computational needs before
launching into such a far-reaching condemnation.
multithreaded programming is not a new thing. many glib-using
applications are heavily (and occasionally massively) multithreaded.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]