Re: Changes to the GLib main loop [ g_main_iterate() ]

[joshua eth net]

On Wed, Jun 20, 2001 at 09:52:48AM +0200, Sebastian Wilhelmi wrote:
> > > > Possibly the right behavior is for the threads to dispatch requests
> > > > round robin, and for the first free thread to start a new cycle,
> > > > ignoring sources currently being dispatched. This would need
> > > > _very_ careful definition, and the combination of this and
> > > > recursion within threads presents a highly complex situation.
> > >
> > > That is true, it sound like a implementation nightmare with no real
> > > benefit. If the user want's to dispatch certain events to other
> > > threads, s/he should use GAsyncQueue or better yet GThreadPool, which
> > > is just for doing that.
> > 
> > I'd tend to agree that the structure should be:
> > 
> >  * One thread handles incoming events, and dispatches all slow
> >    operations to other threads.
> > 
> > It's not the only way people try to write things, but probably we
> > just need to educate people.
> 
> Yes. Also I don't think, this is something that people will often use in
> normal applications. So that shouldn't be a problem.

For what it's worth, i wrote an event loop for Perl.  The code is blind
to threads because i don't know how is it possible to improve upon:

  "One thread handles incoming events, and dispatches all slow
   operations to other threads."

$0.02