Date: Sun, 17 Sep 2000 20:36:16 +0200 From: Peter van Dijk <peter@dataloss.net> To: current@FreeBSD.ORG Subject: Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!) Message-ID: <20000917203616.B11424@dataloss.net> In-Reply-To: <20000916100447.I27034@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Sat, Sep 16, 2000 at 10:04:47AM %2B0200 References: <phk@critter.freebsd.dk> <200009160249.e8G2n3n02415@hak.lan.Awfulhak.org> <20000916100447.I27034@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
> <crazy mode on>
>
> How much sense does it make to think about implementing tee and
> select methods this way? Like "open file1 and file2 and write to
> both of them whatever I give to you" and "give me data coming in
> from whatever file is in this set"? The only problem is to
> determine available characters to separate these names. '+' as
> well as ':', ',' and ';' are perfectly valid characters for
> constructing filenames. '&' seems to be too, but could be used
> rarely enough. And the split upon these new separators actually
> should be done only when the appropriate SDO_ flags are passed.
>
> e.g.
> superduperopen("file1&file2", "a+", SDO_TEEFILES)
> superduperopen("file1&file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
[snip]
> parameters) have to pass certain checks. Nobody should try to
> read from "|command". And I cannot see any use for "write to
> whatever descriptor is ready to write to first" as would result
> from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That feature
should be in there too :)
I do see a use to "write to whatever descriptor is ready first". It
could be used for a very simple multithreading-like implementation.
Spawn 8 child processes, attach them to one stream with
superduperopen(), and pass single-byte commands to one that is waiting
to handle one. If all 8 are busy, you block, or return something like
EAGAIN. This description is very pseudo-something, btw :)
> Feel free to correct the flag's data type. I have the feeling
> not all int's have 32bits. :) Some other means of storage might
int works for open, I doubt whether we need more options than open does :)
> be more appropriate while still being easy to combine and to pass
> to the function. But I feel strings like "STD,PIPE,TEE" are
There's no reason for that. We have a compiler that can parse *unquoted*
strings like STD | PIPE | TEE and create single int's out of that. Ain't
it wonderful :)
> harder to parse and single character notation like the "wt" mode
> flags are harder to find (think of) and to read (in terms of
> eyeballing the source code) for the sdo case.
I do think the "w+" 'n stuff notation in popen sucks. This is our chance
to turn those into bitflags too, for superduperopen anyway.
Greetz, Peter
--
dataloss networks
'/ignore-ance is bliss' - me
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000917203616.B11424>