推 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