If this is implementation behavior and not spec, maybe consider signaling
the notify function after Tcp4->Transmit() finishes its responsibilities?
It would be very useful for asynchronous network operations to be able to
use the socket again in the notify function. The only way I can have
background network operations right now is to set timers or to access the
private data and release the lock myself.
Thomas Rognon
On Thu, Aug 21, 2014 at 8:56 PM, Ye, Ting <ting...@intel.com> wrote:
> Tcp4->Transmit() queues outgoing data into the transmit queue. In
> current implementation, the notify function will be signaled as soon as the
> data is queued, before TCP4->Transmit() finishes all its responsibilities.
>
>
>
> Best Regards,
>
> Ye Ting
>
>
>
> *From:* Thomas Rognon [mailto:tcrog...@gmail.com]
> *Sent:* Thursday, August 21, 2014 11:47 AM
> *To:* edk2-devel
> *Subject:* Re: [edk2] Asynchronous TCP issue
>
>
>
> By callback, I mean the notify function that is passed into Tcp4->Accept()
> / Tcp4->Transmit() / Tcp4->Receive() / etc. I'll say notify function
> instead of callback, since that seems to be the language edk2 uses.
>
>
>
> I have a distinct notify function for each async operation. For example,
> my notify function for Tcp4->Accept() is AcceptCallback() and my notify
> function for Tcp4->Transmit() is TransmitCallback() etc.
>
>
>
> Inside the Tcp4->Transmit() notify function, I want to call
> Tcp4->Receive(). I can't because the socket's lock isn't released until
> sometime after execution returns from the notify function.
>
>
>
> What I did to work around this temporarily is set a relative timer in the
> Tcp4->Transmit() notify function for 100ms. I put the Tcp4->Receive() in
> the timer's notify function. This works because 100ms is enough time for
> the execution to return from Tcp4->Transmit() notify function and release
> the socket's lock. But doing it this way is very inefficient and could
> cause a race condition.
>
>
>
> In other words, why isn't the socket's lock released before the notify
> function is signaled? Shouldn't the notify function be signaled after the
> socket is completely finished with all of it's responsibilities?
>
>
>
> Thank you for being so helpful!
>
>
>
> Thomas
>
>
>
> On Wed, Aug 20, 2014 at 9:29 PM, Ye, Ting <ting...@intel.com> wrote:
>
> The Sock->Lock is defined to protect the sharing data in socket. An access
> to socket interface will acquire the lock at the beginning and release the
> lock at the end.
>
> In your case, would you please describe the “callback finishes” more
> detail? Do you mean the “callback” includes a Tcp4->Transmit() call and you
> need wait for this call finish before entering Tcp4->Receive()?
>
>
>
> Best Regards,
>
> Ye Ting
>
>
>
> *From:* Thomas Rognon [mailto:tcrog...@gmail.com]
> *Sent:* Thursday, August 21, 2014 9:12 AM
> *To:* edk2-devel
> *Subject:* [edk2] Asynchronous TCP issue
>
>
>
> I have a driver that needs to do async TCP in the background while other
> UEFI apps are running. The flow needs to go like this:
>
>
>
> {
>
> Tcp4->Accept(); // async
>
> }
>
>
>
> AcceptCallback() {
>
> Tcp4->Transmit(); // async
>
> }
>
>
>
> TransmitCallback() {
>
> Tcp4->Receive(); // async
>
> }
>
>
>
> This works up until Tcp4->Receive() which immediately returns
> EFI_ACCESS_DENIED. I traced it back to Status = EfiAcquireLockOrFail
> (&(Sock->Lock)); in SockRcv().
>
>
>
> So the socket is locked while in the callback, which is very inconvenient.
> I worked around it by setting a timer to call Tcp4->Receive() a few
> milliseconds later. That way the callback finishes and the socket's lock is
> released before my code is run. I'd rather not do it that way, though.
>
>
>
> Is this intended? Thank you for any insight.
>
>
>
> Thomas Rognon
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
