Created by: bhaan
The current session event loop has a primitive approach toward handling outgoing messages sent from application code. A call to quickfix.SendToTarget essentially adds the message to a queue, which the event loop picks up during it's next pass. This is limiting for applications that want to account for a message send failure, as there is no way for the event loop to communicate that back to application code.
These commits propose the following changes:
- Remove the
toSendmessage queue - Add a dedicated channel in the event loop for sending messages.
- Have
SendToTargetpush messages to the event loop, and block on a corresponding error channel - Force the FromAdmin/App callback to occur on a dedicated goroutine. This creates separation between "application space" and "session space", and is required to prevent deadlocks on calls to
SendToTargetduring the FromAdmin/App callback. - Separate session state message handling into three parts: 1) Vaildation 2) FromAdmin/App callback 3) Processing for admin and rejected messages. This is required to enable the above changes.
Activity
511 487 receiveTime time.Time 512 488 } 513 489 490 type sendRequest struct { 491 msg Message 492 err chan error 493 } 494 514 495 func (s *session) run(msgIn chan fixIn, msgOut chan []byte, quit chan bool) { 496 s.messageIn = msgIn 515 497 s.messageOut = msgOut 498 s.toSend = make(chan sendRequest) 499 s.resendIn = make(chan Message, 1) 500 501 type fromCallback struct { 511 487 receiveTime time.Time 512 488 } 513 489 490 type sendRequest struct { 491 msg Message 492 err chan error 493 } 494 514 495 func (s *session) run(msgIn chan fixIn, msgOut chan []byte, quit chan bool) { 496 s.messageIn = msgIn 515 497 s.messageOut = msgOut 498 s.toSend = make(chan sendRequest) 499 s.resendIn = make(chan Message, 1) 500 501 type fromCallback struct { Created by: bhaan
the size of golang structs I believe are just 8 bytes in addition to the types they enclose. So every time you'd call
run, you'd be allocating, on the stack, 8 bytes + size ofMessage+ size ofMessageRejectError. Which is negligible considering when and how many timesrunis expected to be called.
changed milestone to %v0.4.0
mentioned in issue #162 (closed)
mentioned in merge request !165 (merged)
mentioned in merge request !167 (merged)
mentioned in issue #169 (closed)
