[mythtv] MythSocket class
jwestfall at surrealistic.net
Tue May 30 04:27:59 UTC 2006
Isaac Richards <ijr at case.edu> wrote [05.29.06]:
> On Monday 29 May 2006 1:03 pm, Jim Westfall wrote:
> > Jim Westfall <jwestfall at surrealistic.net> wrote [05.28.06]:
> > > John P Poet <jppoet at gmail.com> wrote [05.28.06]:
> > > > Commented that line out on both backends, but it did not seem to help.
> > > > The slave backend (cobalt) is still not used.
> > > >
> > > > I have attached the resulting logs.
> > > >
> > > > John
> > >
> > > It made it further, but there is another issue.
> > >
> > > MythSocket::readBlock() call is forcing sockets to be put back onto
> > > readyread monitoring, when it might not be wanted.
> > >
> > > I will see about making a patch tomorrow.
> > give this patch a try.
> Hrm. Don't really like making that explicit like that - have to modify
> MythContext as well. I think a check for if the socket is locked or not in
> the select thread should accomplish mostly the same thing.
> Or, we could do all reading of available data into a buffer in that select
It should only been needed if the readyRead() callback doesnt fully read
what it needs to read from the socket. The backend doesnt do any reading
from the socket in readyRead(), its just hands it to a worker thread and
returns. The socket cant be put back onto the select list until
ProcessRequest() returns, since multiple read/writeStringLists can occur
as part of the processing.
I am not sure the normal sock->Lock() will work because
PlaybackSock::SendReceiveStringList() also does a sock->Lock().
The other issue he is still having is the EncoderLink class since it
interacts with the socket on its own to get free space and max bitrate on
the slave backend. It looks like once the slave backend registers with
the master, the master takes control of the socket? If that is the case
we should be able to disable the socket from being on the select list
once ANN SlaveBackend is seen.
More information about the mythtv-dev