Mail Archives: djgpp-workers/1997/10/15/19:19:44
--=====================_876975517==_
Content-Type: text/plain; charset="us-ascii"
The pipe emulation I've just upload has two good points:
1. Two different programs can talk to each other over the pipe. Even on
different PCs if networking or a proper lower-level fsext is employed.
2. It can, theoretically be inherited through a spawn.
and two minor weaknesses:
1. It's circular queue of no more than 250 bytes. I'm working on having
its size bigger at creation time. It will not automatically get bigger.
2. I have a very crude inherit mechanism. I haven't included it because
I'm not sure how would be best.
My best guess is to do the inherit mechanism in this fashion (from the
perspective a starting program):
1. Just before main() is called, three environmental variables are checked:
" !STDIN", " !STDOUT", " !STDERR" (a la proxy). These each have a
formatted message which indicate what file to open and where in the file
the proper circular queue is:
"<ofs> <path>" : Indicates that the path of the file to open and its
offset to use for the queue
"<ofs>" :Indicates that stdin (stdout, or stderr) should be used as is,
and that we should seek to the proper offset.
2. The proper single direction pipe is open accordingly by (for example,
with stdin)
if (use stdin for queue)
new_fd = dup(0);
else
new_fd = open(....);
new_in_fd = _ipc_source(new_fd, ofs); /* Open the single ended pipe */
dup2(new_in_fd, 0);
This works. The trick to using the stdin, stdout, and stderr for both read
and write (required for the circular queue) is that the parent process open
those files as O_RDWR. I've attached some code which demonstrates this.
Some questions:
1. Does the stdio trick work on other machines besides MSDOS?
2. How much pain will it be to get _spawnve ( or whatever) to detect that
stdin, stdout, stderr have been redirected to pipes and pass this
information to the child? (I think the detection part is easy -- just
check to see if there is a handler installed for that handle).
Any comments? Suggestions? Screams of abject horror?
Randy Maas
randym AT acm DOT org
--=====================_876975517==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="Intestc.c"
/* this demonstrates two things under MSDOS
1. Any standard in IO can seek for a read.
2. If the standard in is opened for read and write (as in intestp.c)
the standard in can be seek'd for a write.
*/
#include <io.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
main()
{
char tmp[5] = {0,0,0,0, 0};
lseek(0, 4, SEEK_SET);
read(0, tmp, 4); tmp[5]=0; puts(tmp);
lseek(0, 0, SEEK_SET);
read(0, tmp, 4); tmp[5]=0; puts(tmp);
setmode(0, O_BINARY|O_RDWR);
lseek(0, 0, SEEK_SET);
tmp[0]='a';
write(0, tmp, 4);
lseek(0, 0, SEEK_SET);
read(0, tmp, 4); tmp[5]=0; puts(tmp);
}
--=====================_876975517==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="Intestp.c"
/* this helps demonstrates two things under MSDOS
1. Any standard in IO can seek for a read.
2. If the standard in is opened for read and write (as in intestp.c)
the standard in can be seek'd for a write.
This program does #2 and calls "intestc" to demonstrate that this is so.
*/
#include <fcntl.h>
main()
{
/* First we open test */
int fd = open("test", O_RDWR);
/* Next we set as standard in */
dup2(fd, 0);
/* Spawn to the test */
system("intestc");
}
--=====================_876975517==_
Content-Type: text/plain; charset="us-ascii"
--=====================_876975517==_--
- Raw text -