On Sat, Jan 8, 2011 at 6:24 PM, Lyndon Nerenberg (VE6BBM/VE7TFX)
wrote:
>> thinking about it... why not just let stream() fail and let the program
>> decide if it makes sense to continue without it?
>
> Exactly what I was thinking. If the program requires the semantics of
> stream(), it should be
> thinking about it... why not just let stream() fail and let the program
> decide if it makes sense to continue without it?
Exactly what I was thinking. If the program requires the semantics of
stream(), it should be able to reliably discover when they aren't
available.
that, should have been:
if((sfd = stream(fd)) >= 0){
dup(sfd, fd);
close(sfd);
}
--
cinap
--- Begin Message ---
On Sat, Jan 8, 2011 at 4:31 PM, wrote:
> the use of tcp to get flow control is an interesting idea.
>
> some remaks:
>
> the client only gets the dial string of a new
thinking about it... why not just let stream() fail and let the program
decide if it makes sense to continue without it?
way simpler than the struct Stream bookkeeping or returning a pipe
and spawning a relay process in the background.
fd = open();
/* use streaming if possible */
if((sfd = s
> This ought to work, but I wanted to establish a difference between
> regular fds, which you can read and write and seek and all that
> goodness, and streams, which are for reading OR writing sequentially.
i'm not sure why one would want this. there are already fds on
which must be read or writt
On Sat, Jan 8, 2011 at 4:31 PM, wrote:
> the use of tcp to get flow control is an interesting idea.
>
> some remaks:
>
> the client only gets the dial string of a new tcp connection. an
> attacker could guess the port numbers and take over the stream. or
> the client might be delayed before it
the use of tcp to get flow control is an interesting idea.
some remaks:
the client only gets the dial string of a new tcp connection. an
attacker could guess the port numbers and take over the stream. or
the client might be delayed before it makes the dial() causing it to
get the wrong stream o
Awesome!
On Fri, Jan 7, 2011 at 11:24 PM, John Floren wrote:
> Ok, now that the thesis is signed, I feel ready to release my work on
> streaming for 9P, as outlined in my talk at IWP9; things have changed
> a lot since that talk, but the general idea remains the same. The
> repository at https:/
Cool. We spoke briefly in Seattle. It's perfect for CDM Midi and SPDIF.
I haven't seen the video of you as the sacrificial lamb ... I need it.
brucee
On 1/8/11, Seed wrote:
> 11 at 6:24 PM, John Floren wrote:
>> Anyway, it's far from perfect, but any comments, patches, or
>> suggestions are ap
11 at 6:24 PM, John Floren wrote:
> Anyway, it's far from perfect, but any comments, patches, or
> suggestions are appreciated.
Hi John,
I just quickly went through your thesis, was nice to read.
If the stream() function in you thesis is the last one it seems that
there is an obvious memory leak
Ok, now that the thesis is signed, I feel ready to release my work on
streaming for 9P, as outlined in my talk at IWP9; things have changed
a lot since that talk, but the general idea remains the same. The
repository at https://bitbucket.org/floren/tstream/ contains my code
and the thesis documents
11 matches
Mail list logo
