On Wednesday 11 September 2002 5:56 pm, Lars Gullik Bjønnes
wrote:
> | I think that your sockets are similar in this respect to my
> | "client" pipes. Multiple "clients" can connect to existing
> | pipes lyxpipe.in/out and communicate with lyx
> | simultaneously.
>
> As I showed with pipes... this is not possible.
> (it is a pipe dream to think so)
I understand your point but contend that your English is too
good. Stop that!
> | Basically, I think that pipestream is a high level class and
> | the actual communication is very low level (little more than
> | wrappers for ::open(), ::close(), ::read() and ::write()).
> | It /must/ be possible to hide the low level rubbish inside
> | the stream.
>
> Close but not quite. New connections (when speaking socket)
> must be handled with an accept. The fd returned from this
> accept can be passed to a socket_buf, and the rest can then be
> handled by your stream. (except that you now have to prepared
> to handle multiple streams at the same time.)
....so the socketstream will indeed differ semantically from
pipestream. It will have
class socketstream {
///
boost::function1<void, int> input_received;
///
socketstream & operator[](int fd);
};
whilst pipestream will have
class pipestream {
///
boost::function0<void> input_received;
};
Ie, the socketstream will emit a callback passing the fd that
has received something interesting to the socketstream owner
which would extract the info with
socketstream ss;
input_ready(int fd)
{
ss[fd] >> ...
}
I'm sure that we can address this as it arises.
> | Anyway, my original problem still remains ;-)
> |
> | The pipestream works only if I add those last two lines:
> |
> | string const pipebase = "/home/aleem/.lyx/lyxpipe";
> | Pipestream ps(pipebase.c_str());
> |
> | vector<string> stuff_to_print;
> | vector<string>::const_iterator it = stuff_to_print.begin();
> | vector<string>::const_iterator end = stuff_to_print.end();
> | for (; it != end; ++it) {
> | // endl flushes the pipestream buffer
> | ps << *it << endl;
> | // for some reason this sets eof, so ...
> | if (ps.eof())
> | ps.clear();
> | }
>
> That clear resets some stream flags right (stream state).
>
> So if you have reached eof then the stream goes into a failure
> state, this failure state must be cleared if you want to
> receive anything else.
>
> (or write for that matter)
Hmmmm. So you're saying that a failed attempt to read will set
eof. Thanks,
This certainly can happen under Tru64 unix because of the
::select point I mentioned separately. I'll think about it.
Angus
