推 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