我一直在尝试围绕FIFO,并提出了一个简单的服务器和客户端程序.
我不是想做任何花哨的事情,只是为了让一个进程扮演’服务器’的角色,这个过程将“监听”另一个进程传递的任何消息;客户端.
这是我写的：
server.c
#includedio.h>
#include 正如你所看到的,当我在./server.out&的背景下运行时,这非常简单.它在读取调用时被阻塞,并等待任何人写入clientToServer.fifo.到现在为止还挺好.
现在,考虑客户端：
client.c
#includedio.h>
#include 这是客户.也很简单的代码.当我从shell运行./a.out时,它可以工作 – 它发送消息,而server.out进程打印你发送％s到服务器.
问题是,当我通过客户端将Quit发送到服务器时,尽管a.out进程根据需要终止,但server.out中的while循环也会中断.意思是,read不再阻塞server.out进程并等待其他客户端,而是服务器程序与客户端一起结束.
为什么会这样？即使在a.out进程结束后,read也不应该再次暂停server.out？
when I ran this at background with ./server.out& it’s blocked at the read call and waiting for anyone to write to clientToServer.fifo
实际上它在开放时阻止.这是FIFO工作的方式.打开(在阻塞模式下)将阻塞,直到另一端打开FIFO.
the while loop in the server.out breaks as well. meaning,the read no longer blocks the server.out process and awaits other clients,instead,the server program ends
同样,这是正常行为.只有一个客户端进程连接到FIFO,因此当它关闭时,则发送EOF并退出服务器.如果同时将多个客户端连接到FIFO,则在最后一个客户端关闭它之前,您将看不到EOF.如果您希望长时间运行的服务器连续为多个客户端提供服务,最简单的方法是将服务器的FIFO打开为读/写.这种方式总是有一个读写器 – 服务器本身 – 即使最后一个客户端退出也不会看到EOF.当关闭服务器的时候,然后关闭服务器中的适当的一端,让自然在真正的客户退出时采取自己的方式.
