Re: [gnet] Problems with GNet and GIOChannels...

[Tim Müller <tim-mailinglists zen co uk>]

On Friday 20 August 2004 14:23, James Wiggs wrote:

> > Have you tried GConn instead? Not sure if GConn is still marked as
> > experimental, but I've made good experiences with it, and the API is
> > _much_ simpler than GTcpSocket.
>
>    I'm all for simpler, believe me, but not at the expense
> of stability.  I can't emphasize enough how important it is
> that these processes be as solid as granite.  Can any of the
> GNet developers chime in with an opinion on how stable GConn
> is right now?  I chose GTcpSocket specifically because GConn
> is labelled in the documentation as "experimental."

GConn is basically just a wrapper around GTcpSocket anyway. I always thought 
that the 'experimental' was in reference to API stability and not to the 
stability of the code itself. Don't really know for sure though. However, 
unless I'm mistaken it's not marked as 'experimental' any longer.


>    My programming here reflects my past experience writing
> parallel numerical analysis codes for massively parallel non-
> shared memory machines.  I'm very comfortable with the concept
> of processes passing messages to each other, so I chose that
> methodology for coordinating between processes.  Not saying
> your solution isn't better, just that it isn't a natural way
> of modeling the problem for me.  There will be a *lot* of
> these messages; I figure the overhead of maintaining the AMQ
> would be less than setting up this idle callback and then
> inserting it into another thread's context.  There would have
> to be locking implemented on that thread's context, as well,
> right?

well, yes. g_source_attach() will need to lock the context you're inserting 
into; however, the same goes for g_async_queue_push(), which will need to 
lock the GAsyncQueue you're pushing data onto. The thing you save with 'my' 
method is the constant polling of the GAsyncQueue (and the additional locking 
that g_async_queue_try_pop() entails). Anyway, was just a suggestion.


> How much overhead is really involved in setting
> up an idle callback and then inserting it into the context of
> another thread?

I'd say less than pushing data and then constantly polling the GAsyncQueue, 
because you only need to lock the context once, and then the data is within 
the scope of the context, whereas you need to lock the async queue at least 
once for the push and once for the pull. Just a wild guess though, I haven't 
looked into this in detail.



>    I'd love to do this, but the problem is the code is intimately
> tied to the hardware receiver, so no test program could really show
> the full context.  I don't know how to get around that problem.  I'm
> going to be rewriting some parts of the code over the next few days
> and testing it again on Monday.  Hopefully I will have a better grip
> on things then.

You mean if you pipe packets from /dev/random over your TCP connection as fast 
as possible, then you don't get this effect with your code?

Cheers
 -Tim