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);

> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to