[mythtv] MythSocket class

[Jim Westfall]

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 
> thread.

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.

jim