COM and common data per instance
Because each client would have a different view of the data. All of them
would not be reading at the exact same time, so if each client is to get all
the data from the COM port, they would need their own buffers. Unless there
is another way, like having one really big server-side buffer and using
client indices into it. Like I said though, this was a self-tutorial, to
see what I could do with COM.
Yamin
Quote:
> Why bother copying from the COM port to N buffers ? If all threads read
the
> same input from the COMM port just use one buffer. Copying is overhead and
> maintaining which thread has which buffer is overhead too.
> > Hey all,
> > What I would like to do is have a common data object that all instances
> > would have access to. This is more of a self tutorial, so if it does
not
> > seem like it has any practical value, then that's okay. Maybe this is
> kind
> > of contradictory to COMs model, but let me give an example.
> > This is just a stupid example, but bare with me. Suppose I want a COM
> > object that supports the following:
> > SetCommPort(int commport)
> > SetBufferSize(int size)
> > ReadBuffer(int* x)
> > The object communicates with the computer's COMM port, and stores the
last
> X
> > (set by SetBufferSize() ) number of bytes. You can get this buffer by
> > calling ReadBuffer. Any instance of this object will read the same data
> at
> > any given time.
> > The other more practical example, would be to have each instance have
its
> > own buffer. Such that if I create an instance of this COM object, a
> buffer
> > is created for my instance, and any new data is copied to all buffers.
So
> > any number of objects can view the data coming from the COMM PORT. This
> COM
> > object is can run remotely such that you can get the data from the COMM
> PORT
> > from a remote computer.
> > How would the declaration look for this? The code itself shouldn't be
> that
> > bad, but the structure is a bit confusing.
> > Thanx for any help,
> > Yamin
