[Paraview-developers] Casual Weekend Read: ProcessModule 2.0
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Mon Jul 19 17:28:01 EDT 2010
Pat,
On Mon, Jul 19, 2010 at 3:48 PM, pat marion <pat.marion at kitware.com> wrote:
> Currently vtkProcessModule forwards most of its work to
> vtkProcessModuleConnectionManager, so I assume when we discuss
> vtkProcessModule we mean vtkProcessModule +
> vtkProcessModuleConnectionManager.
Yes and no. ProcessModuleConnectionManager pretty much disappears.
Connection management related code moves to ProcessModule
(RegisterConnection etc.), while Connection setup related code moves
to a TransportManager.
> Toward the end, the wiki implies there will be new api for creating custom
> vtkConnection subclasses. Sounds great! So the earlier mentioned method
> AcceptConnectionsOnPort(int port) seems kind of underpowered. The signature
> needs to be something like
>
> AcceptConnectionsOnPort(int port, ...)
>
> where "..." specifies a callback- or a factory- some logic to decide which
> vtkConnection subclass should be constructed to communicate on that port.
> Right now the connection type is hardcoded based on the process type.
Well, we'll move this to TransportManager, but even then, this doesn't
result in creation of a vtkConnection (or subclass), this is just a
transport level call to accept socket connections (for example), once
a connection is received, the TransportManager will fire an event
saying "A new client connected on port-id 12, here;s the socket to
talk with it". Let me add some more stuff to the Wiki explaining how a
vtkConnection will be created. That should make it easier to discuss
this.
> Are we going to continue having just one vtkClientServerInterpreter? How to
> go about coordinating CS-IDs? Previously you mentioned the idea of having
> each client request a batch of contiguous IDs from the server. In the case
> of my coprocessor work, there are actually two servers- the coprocessor is
> equivalent to a symmetric pvbatch (where pvbatch is a client + builtin
> server), and it connects to a pvserver. Some vtk objects exist on the
> coprocessor's builtin server, some vtk objects exist on the pvserver. Will
> the new servermanager GUID scheme make this a non-issue?
GUID and CID together help unquiefy an ID. Remind me again, in your
case the client is not the one that's connecting to the "co-processor"
right? It's the pvserver that connects to the co-processor. Is that
correct?
> When a server has more than one client connection, GetLastResult breaks
> down. Maybe it should be an atomic operation? When you call SendStream you
> would specify whether or not you want to receive the result.
GetLastResult()/SendStream() no longer exist. All you have are atomic
PushState()/PullState() actions (refer to
http://paraview.org/ParaView3/index.php/ServerManager_2.0)
Utkarsh
More information about the Paraview-developers
mailing list