Re: [Valgrind-users] [NRR] RedHat 8.0 pthread "problem"

[Beau D. S. <sim...@ha...>]

> >  o Main thread loops, checking a list of remote request handlers to see
> > if one of them needs to be queued up for a client [most of them are
> > scheduled based on time, some of them based on other criteria]. If a
> > request handler is ready to be executed, it pushes a request onto one of
> > two client connection queues.
> >
> >  o Two client connection threads wait for new requests to show up in
> > their queues. When one is found, a connection is opened if one isn't
> > already opened, the request is sent to the server, and the response is
> > read. Connection closes after X number of seconds that the connection
> > hasn't been used.

> I have to ask -- why are you using threads here?
> What you've described would work well, and would
> scale better, using nonblocking i/o and sys_epoll...
> - Dan

[NRR] - I wanna answer 'cus I think I can get some good input from some of
ya'll, but this response post really isn't valgrind related.

The short answer? Because I was unable to find a good reference to base my
code off of? =) As I said, I'm more of a Perl guy, and I have never really
done much with sockets before either. [didn't mention that the first time
around, d'oh]

Longer answer?

There are going to be some queries that I know are going to take 5-35
seconds. During that time, I may be required to make some
as-close-to-realtime-as-possible requests to the application server. So I
figured I'd just send all of the "short" requests through one connection and
send all "long" requests through another. This way, I can be assured that an
urgent request will be able to get through to the application server sooner
rather than waiting for a 20 second request to be finished.

Remember, this is a client. The application server end [not where I'm having
the problem] is handled by X number of fork()ed processes and [IIRC] uses
select.

Maybe there is a way to do these two clients with nonblocking IO? If you
have any good references for how to accomplish something like this, I'd be
very happy to have a look at them. Most of the references I found were on
how to handle multiple inbound connections from a server standpoint, not
multiple outbound connections from a client standpoint.

Even longer answer?

The other part of the application [that I haven't talked about yet] is a few
inbound connection listeners that will accept connections (TCP and UNIX
sockets) and "do stuff." It is not just a client, but a server as well.
Which is why I need to be able to pass on requests as fast as possible out
the "short" application server client thread, even if there is a long
request already in process. [I have all of the server stuff disabled right
now -- the core is finished, but I wanted to cleanup the client stuff before
I moved on to that....]

I threaded it because I wanted to localize each group of processes and not
manage everything at once in one place.


[daemon client] --,
[daemon client] --+----> [(daemon)] =======> [application server]
[daemon client] --'

Daemon is the application in question. It needs to make periodic/scheduled
requests to an application server. It needs to handle incoming requests from
daemon clients. Based on various things [including daemon client requests],
daemon may need to make one-off requests of the application server that need
to respond quickly.

To be honest, I really can't even begin to imagine how to do this without
threads, and I certainly can't imagine it being easier to implement and
manage any other way. But I'm new... =) *any* help on this would be greatly
appreciated though. If I saw a great reference as to how someone is doing
something similar w/o threads, I might just jump on it.


Thanks!


Beau D. Simensen
http://www.halogen.org/