Graham Barr wrote:
Can you help me to understand the reason for the reuse of the request
message object for holding the response message?
Again, where do you see it reusing the request message for holding the
response ? There are no request message objects, per se. The process of
sending a message generates an object of which the purpose is for
gathering the response
The response gathering message object is responsible for the encoding of
the request. The encoded request is written to the "pdu" attribute of
the message object, the message object is passed to _sendmesg(), where
the pdu is written to the ldap socket. The message object is the stored
in net_ldap_mesg and used to store the response pdu later on. For me,
the request processing, that is done in the message class, is a strong
indication for reuse.
And if I get it right there is the assumption that each request has zero
or one corresponding response messages. That doesn't work well with
IntermediateResponse or ExtendedPartialResponse messages.
Even if you don't call _forgetmesg() in Message::decode for these
responses, you still have the problem, that when you have multiple
asynchronous ldap requests on the same Net::LDAP object, calling
Message::sync, Net::LDAP::sync($mid) or Net::LDAP::process($mid) for one
of the parallel requests will lead to the potential loss of response
messages for all the other requests, because when process() receives
more then one response message for another pending request, only the
last message will survive (see Net::LDAP::process).
You could use callbacks to prevent the message loss, but that would mix
up different programming models.
Or am I missing something?
Daniel
