[boost] Re: Any interest in iostream-like pipe?
Larry Evans wrote:
> [snip]
> indicating some interest in combining thread safety and
> decoration. It seems to me (a novice in threading) that
> what needs to be protected is the access to the end
> of the pipeline, i.e. the final streambuf, which is
> connected to the actual output medium (a file, or console or
> pipe).
Mine isn't connected to the actual medium. It works for yourself (and for
pipe streams).
> Hence, I'm wondering if it's a good idea to
> combine the two in a ostream class. I confess I haven't
> looked at your code, but I think it would be nice if
> somehow it could be streambuf thread safety could be separated
> from the {o,i}stream features which are only concerned with
> formatting. Does that make sense?
Only pipestream is thread safe. Iostreams are not.
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > There is another pipestream project you can take a look at: > http://pstreams.sourceforge.net/ > > There was also another former implementation in the Gnu Gcc lib but it was > discarded, I don't know why. I have a unix-only sort of work in progress which does something similar, but provides multi-stage pipelines (rather than just single process streams) and synchronous pumping of data from multiple pipe stages into and out of streams. it uses a sort of bourne-shell-like syntax of operator overloads, ostensibly to make it easier to whip off little C++ "scripts" for day-to-day tasks. I am starting in on a windows port of it currently, but intended to submit it here for review when complete. it needs cleaning up obviously, but I'd like to see something of the sort make it into boost too. http://www.venge.net/cgi-bin/cvsweb.cgi/venge/code/src/process/ -graydon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
Bohdan wrote: > "Alexander Nasonov" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> graydon hoare wrote: >> > an inter-thread pipe might also be referred to as a synchronization >> > channel, if you want to avoid confusion about names (pipes being a >> > particular OS object). >> > >> > -graydon >> >> Synchronization channel sounds good except that stream names are too >> long. >> >> synchronization_channel channel; // good >> >> // too long? >> synchronization_channel_istream in(channel); >> synchronization_channel_ostream out(channel); >> > > What about shell_stream ? Mine is not shell stream. It has nothing common with stdin/stdout of shell commands :) There are two kinds of pipe: (a) shell feature (aka out_cmd | in_cmd under unix) and (b) OS object. Win32 pipe objects are described here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/pipes.asp UNIX pipe function: http://www.umbi.umd.edu/cgi-bin/man-cgi?pipe+2 UNIX popen/pclose (these functions are close to shell_stream) http://dell5.ma.utexas.edu/cgi-bin/man-cgi?popen+3 -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
Philippe A. Bouchard wrote: > There is another pipestream project you can take a look at: > http://pstreams.sourceforge.net/ May be I missed something but this library is about reading from stdin and writing to stdout of other process. It's not about inter-thread pipes. -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
"Alexander Nasonov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > graydon hoare wrote: > > an inter-thread pipe might also be referred to as a synchronization > > channel, if you want to avoid confusion about names (pipes being a > > particular OS object). > > > > -graydon > > Synchronization channel sounds good except that stream names are too long. > > synchronization_channel channel; // good > > // too long? > synchronization_channel_istream in(channel); > synchronization_channel_ostream out(channel); > What about shell_stream ? regards, bohdan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
graydon hoare wrote: > an inter-thread pipe might also be referred to as a synchronization > channel, if you want to avoid confusion about names (pipes being a > particular OS object). > > -graydon Synchronization channel sounds good except that stream names are too long. synchronization_channel channel; // good // too long? synchronization_channel_istream in(channel); synchronization_channel_ostream out(channel); -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
Alexander Nasonov wrote: > All of you know what is pipe and what are iostreams. In this library > they work together. > Writer-thread put objects into pipes while reader-thread get them > from the pipe. Ålthough objects are copied to/from pipe, this is > often a better alternative to object sharing because the pipe manages > inter-thread communication for you. Thus, you can concentrate on > domain logic rather then on threading primitives. > Unlike OS-provided pipes that operate with bytes of data this library > is iostream based. It means that you work with objects. > The library doesn't use OS pipes. Pipe support is implemented by hand > with a help of Boost.Threads. Synchronization occurs only in > underflow, overflow, sync, open and close functions which means fast > I/O. > The library also has two capacity models: limited and unlimited. In > the former case, if writer goes ahead of a reader it stops and waits; > in the latter case, the writer always allocates new block of memory > when overflow occurs. [...] There is another pipestream project you can take a look at: http://pstreams.sourceforge.net/ There was also another former implementation in the Gnu Gcc lib but it was discarded, I don't know why. Philippe ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Any interest in iostream-like pipe?
> Larry Evans wrote:
>
> > [snip]
> > indicating some interest in combining thread safety and
> > decoration. It seems to me (a novice in threading) that
> > what needs to be protected is the access to the end
> > of the pipeline, i.e. the final streambuf, which is
> > connected to the actual output medium (a file, or console or
> > pipe).
>
> Mine isn't connected to the actual medium. It works for yourself (and for
> pipe streams).
>
> > Hence, I'm wondering if it's a good idea to
> > combine the two in a ostream class. I confess I haven't
> > looked at your code, but I think it would be nice if
> > somehow it could be streambuf thread safety could be separated
> > from the {o,i}stream features which are only concerned with
> > formatting. Does that make sense?
>
> Only pipestream is thread safe. Iostreams are not.
I made them thread-safe ;)
Anyway, the point is that I'm interested in iostream-like pipes.
I wanted to download them, but I dunno what the problem was, but could
not convice yahoo to give it to me :(
Will try again later.
Best,
John
>
> --
> Alexander Nasonov
> Remove minus and all between minus and at from my e-mail for timely
response
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
Alexander Nasonov <[EMAIL PROTECTED]> writes: > Philippe A. Bouchard wrote: > > > There is another pipestream project you can take a look at: > > http://pstreams.sourceforge.net/ > > May be I missed something but this library is about reading from stdin and > writing to stdout of other process. It's not about inter-thread pipes. hm, yes, there appear to be two discussion threads tangled up here, I too got this discussion confused with Jeremy Siek's thread "process control, fork/pipe, etc." an inter-thread pipe might also be referred to as a synchronization channel, if you want to avoid confusion about names (pipes being a particular OS object). -graydon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Any interest in iostream-like pipe?
>
> http://lists.boost.org/MailArchives/boost/msg46513.php
>
> indicating some interest in combining thread safety and
> decoration. It seems to me (a novice in threading) that
> what needs to be protected is the access to the end
> of the pipeline, i.e. the final streambuf, which is
> connected to the actual output medium (a file, or console or
> pipe). Hence, I'm wondering if it's a good idea to
> combine the two in a ostream class. I confess I haven't
> looked at your code, but I think it would be nice if
> somehow it could be streambuf thread safety could be separated
it is, in the library I developed.
It's quite cute and efficient too ;)
Unfortunately I haven't had time to do the docs, since other stuff
too over.
Maily, SMART_ASSERT - which I want to finish the docs for ;)
and then I want to create a wingui.
And I have a job also ;)
But, if there's interest in it, I'll make some time.
Otherwise, it'll wait a couple more months :(
Best,
John
> from the {o,i}stream features which are only concerned with
> formatting. Does that make sense?
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
