Blocking on fopen() command

[Twiggy182]

Hi,

I tried to run the following C code but it get stuck on the "fopen()"
commande. Is there someone that can help me with that?

=============================
FILE *dps=NULL;
if (mkfifo(MY_NAMMED_PIPE, 0777)) {
perror("Error with Server FIFO");
exit(1);
}

dps=fopen(MY_NAMMED_PIPE,"r");
if(dps == NULL)
{
perror("Error opening the FIFO\n");
exit(2);
}
===============================

Thanks a lot

 

[Jack Klein]

Hi,

I tried to run the following C code but it get stuck on the "fopen()"
commande. Is there someone that can help me with that?

=============================
FILE *dps=NULL;
if (mkfifo(MY_NAMMED_PIPE, 0777)) {
perror("Error with Server FIFO");
exit(1);
}

dps=fopen(MY_NAMMED_PIPE,"r");
if(dps == NULL)
{
perror("Error opening the FIFO\n");
exit(2);
}
===============================

Thanks a lot

Whatever "mkfifo" is, it is not standard C. You had best take it up
in a group for your compiler/operating system combination, it's
off-topic here.

 

[Darrell Grainger]

Hi,

I tried to run the following C code but it get stuck on the "fopen()"
commande. Is there someone that can help me with that?

=============================
FILE *dps=NULL;
if (mkfifo(MY_NAMMED_PIPE, 0777)) {
perror("Error with Server FIFO");
exit(1);
}

dps=fopen(MY_NAMMED_PIPE,"r");

What data type is MY_NAMMED_PIPE? The mkfifo function is not standard C so
I have no way of knowing what it does or what type MY_NAMMED_PIPE is. Even
if MY_NAMMED_PIPE is a string or pointer to a string, I would also need to
know what is in the string. Maybe it is not a valid filename for your
operating system.

You might want to add:

printf("'%s'\n", MY_NAMMED_PIPE);

before the fopen to be sure the name is valid. Anything beyond that and
you will have to ask in a newsgroup that deals with your operating system.

 

[Gordon Burditt]

I tried to run the following C code but it get stuck on the "fopen()"

commande. Is there someone that can help me with that?

There are a number of system-specific reasons why opening certain
somethings that aren't a regular file are supposed to block waiting
for some event, but the reason they are supposed to block isn't ANSI C.

<OFF TOPIC>
1. A serial port, depending on how it is configured, may block until carrier
detect is raised on the modem (it gets an incoming call, or an outgoing
call connects).
2. A FIFO opened for read may block if no one has it open for write until
someone does open it for write. Often, if you want it to return immediately,
you can open it for read-write even if you don't intend to write: since
someone has it open and COULD write, it returns immediately. Since you're
calling it a "Server FIFO", this may be what you want to do.
3. A raw disk device may block until the disk is inserted and spins up.
This may take a while to fail if there is no disk in the drive.
4. Even regular files on remote file systems may take a lot of time to open
if the server on which they are located is rebooting (e.g. NFS hard mounts).

=============================
FILE *dps=NULL;
if (mkfifo(MY_NAMMED_PIPE, 0777)) {

I presume MY_NAMMED_PIPE is a string or pointer to a legal file name
that can be created.

perror("Error with Server FIFO");
exit(1);
}

dps=fopen(MY_NAMMED_PIPE,"r");
if(dps == NULL)
{
perror("Error opening the FIFO\n");
exit(2);
}
===============================

Thanks a lot

<ON TOPIC>
The standard-blessed arguments to exit() are 0, EXIT_SUCCESS, and EXIT_FAILURE.
1 and 2 aren't necessarily in that set, and even if they are in your implementation,
they aren't guaranteed to be everywhere.
</ON TOPIC>

Gordon L. Burditt

 

[Dan Pop]

The standard-blessed arguments to exit() are 0, EXIT_SUCCESS, and EXIT_FAILURE.
1 and 2 aren't necessarily in that set, and even if they are in your implementation,
they aren't guaranteed to be everywhere.

The standard-blessed arguments to exit() are the whole [INT_MIN, INT_MAX]
range. Some values have slightly better defined semantics than others,
but all of them result in an implementation-defined exit status.

Dan