推 iippchen:如果customer在write well-known FIFO前就close specific 06/07 20:40 → iippchen:FIFO,就可以保证在reseller write specific FIFO前close 06/07 20:41 → pishen:如果customer在write well-known FIFO前就open specific 06/08 13:42 → pishen:FIFO for block,应该就会卡住了吧,因为reseller还没收到 06/08 13:43 → pishen:request,根本就不会open specific FIFO 06/08 13:43 如果依照我这段推文的方法，的确会卡住。 在批改abnormal case1时, 我的customer会作以下动作 1. create and open well-known FIFO for write 2. thinks for 1~3 sec 3. write request to well-known FIFO 4. open specific FIFO for read 5. close specific FIFO 这样又可能会发生reseller先write specific FIFO, 然後customer再close specific FIFO, 使得SIGPIPE不会发生。因此建议大家的reseller在open与write specific FIFO 之间作一点事情，如设定message的值、sleep等，以减少reseller先write的机率。若 还是发生reseller先write的情况，我会再看Reseller.c，若有正确设定signal handler的话，仍可以拿到分数。 不好意思之前没有发现这问题，造成大家的困扰<(_ _)> --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.28.103