Re: Master/worker design
From: Benjamin Riefenstahl (Benjamin.Riefenstahl_at_epost.de)
Date: 08/09/04
- Next message: Jeff Hobbs: "Re: Not work .tbc"
- Previous message: Bryan Oakley: "Re: TCL top level question"
- In reply to: Igor Volobouev: "Master/worker design"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 09 Aug 2004 17:05:06 +0200
Hi Igor,
Igor Volobouev <IVolobouev@lbl.gov> writes:
> 1) I am trying to multiplex text and binary data on the same socket.
> To do that, I want to transmit the length of the binary object in
> bytes before the object itself. What is the best way to determine
> a length of such an object? Would "string length" work reliably
> on a binary, or should I get it from Tcl_GetByteArrayFromObj?
You will have to configure your sockets as [fconfigure -translation
binary].
[string length] will tell you the number of elements in any string.
If your object is binary data (a string with pseudo-characters with
values 0 to 255), the result of [string length] will be the number of
bytes.
If your data is text (a string with any Unicode character \u0000 to
\uFFFF), you need to convert this to binary with [encoding convertto]
before you can measure and transmit it. If you use
Tcl_GetByteArrayFromObj() on a text string or with a binary socket and
you don't convert it to some byte-wise encoding before use, than the
result will be corrupted for all Unicode characters > \u00FF.
> Should I worry about shimmering effects (transmitted a binary,
> received a string, etc)?
This is not a problem of the Tcl_Objs (shimmering). *You* as the
programmer have to know whether you are dealing with bytes or with
characters at each stage of your processing.
> 2) Is there a way to pack an interpreter with all its variables and
> procedures, ship it to another computer over a socket, and unpack
> it there? It seems like the most convenient way for a master to give
> the worker all necessary tools to perform the job.
You may get problems with state that is carried in binary subsystems
or extensions. E.g. open files handles, database connections, OLE
objects, etc. If and how you handle these depends on your
application.
Other than that you can enumerate all namespaces (recursivly) and all
the variables and procs in them. See [namespace children], [info
variables], [info commands], [info body], [info default], etc. You
can use these bits to create Tcl scripts that you can send to the
other side for execution and that will recreate your environment.
Of course you should not transfer variables or commands that refer to
state that may be different between local and remote, like
e.g. tcl_platform, argv (probably) or auto_path.
All in all, it's probably safer to limit yourself to a set of
variables and procs that you define yourself instead of trying to be
generic.
benny
- Next message: Jeff Hobbs: "Re: Not work .tbc"
- Previous message: Bryan Oakley: "Re: TCL top level question"
- In reply to: Igor Volobouev: "Master/worker design"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
