• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [NKE]socket_receive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NKE]socket_receive


  • Subject: Re: [NKE]socket_receive
  • From: James Chan <email@hidden>
  • Date: Fri, 14 Mar 2008 12:57:55 +0800

Hi Terry and Quinn,

Thank your reply.

My sample program is using an upcall, but it still return EWOULDBLOCK.

this is my create socket connection procedure
1. sock_socket(PF_INET, SOCK_STREAM, protocol,(sock_upcall)&my_sock_callback, (void *)cookie, &so);
2. set_nonblocking();
3. sock_connect(so, (sockaddr*)&to, MSG_DONTWAIT);
4. sock_send(so,&msg,0, &len);


===========================================================
void my_sock_callback(socket_t so, void* cookie, int waitf)
{
   errno_t err;
   mbuf_t data;
   size_t len;
   unsigned char counter = 0;

   if (cookie != (void *)ULTIMATE_ANSWER) return;

   do{
       len = 1460;
       err    = sock_receivembuf(so,NULL,&data,MSG_WAITALL,&len);

USBLog(3, "[VHCI][my_sock_callback][%d] err = %d, len = %d", counter, err, len);

       IOSleep(100);
   }while(err == EWOULDBLOCK && counter++ < 10);

return;
}
==============================================================

But It still return EWOULDBLOCK.


Regards, James Chan

Quinn wrote:
At 6:36 -0400 13/3/08, Terry Simons wrote:
In a normal application this might be handled by attempting to read, and then sleeping for some small amount of time if EWOULDBLOCK is received, then atempting to read again.

That's not a good idea. Effectively this means that you're polling for the data, which wastes CPU (and power) and limits your response time. A better solution is to add the socket to some sort of event that you can block on. Commonly this involves calling <x-man-page://2/select> or creating a <x-man-page://2/kqueue>.


Sleeping is necessary to avoid pegging the CPU, but I'm not sure what the recommendation would be in an NKE.

This is trickier in an NKE context. You have a couple of choices:

o switch the socket to blocking mode -- This is only appropriate if you can guarantee that the thread that you're running on can be blocked.

o use an upcall -- When you create the socket you can supply pointer to a routine that is called when data becomes available. Looking in <sys/kpi_socket.h> for sock_upcall.

Share and Enjoy


--
James Chan
Software Engineer
Elitesilicon

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: [NKE]socket_receive
      • From: Adi Masputra <email@hidden>
References: 
 >[NKE]socket_receive (From: James Chan <email@hidden>)
 >Re: [NKE]socket_receive (From: Terry Simons <email@hidden>)
 >Re: [NKE]socket_receive (From: Quinn <email@hidden>)

  • Prev by Date: Re: [NKE]socket_receive
  • Next by Date: Re: [NKE]socket_receive
  • Previous by thread: Re: [NKE]socket_receive
  • Next by thread: Re: [NKE]socket_receive
  • Index(es):
    • Date
    • Thread