no-block socket problem, is this a vxWorks's bug?


    Sponsored Links


  • 1. Is mutual-exclusion always using SEM_Q_PRIORITY!!!
    Hi, Please put some light on these MUTEX lib semMCreate(): 1. To avoid priority inversion the task which owns a resource will execute at the priority of the highest priority task blocked on that resource => so 2. what I understand is, any semM is always created using the SEM_Q_PRIORITY, option... what about if any other option is specifed?? Thanks Srinivas
  • 2. Kernel instructions!!
    Hi All, UNIX books talk about privileged instructions which can be executed only by the kernel. I there something like that in the VxWorks kernel? I wonder if anybody has worked on VxWorks kernel except for some old timers in WRS!! If yes, please let me know why they are needed if there is no user mode/ kernel sort of a concept in VxWorks? Thanks, ASM
  • 3. vxworks core file-doubt!!!
    Hi all, Sorry if this query looks too amature.I have been using vxworks in our project and just would like to know what exactly is this core file?My understanding is core file is one which contains some bsp stuff and some kernel stuff.Is my assumption correct?Who gives this core file?Is it supplied by windriver?I use vxworks5.5 tornado2.2 and MIPS target.Also in the target configuration dialogue box we supply this path where this core file is present.I had a doubt whether this should be symbol table for our image? Sorry once again if this query looks absurd,but I dont have anyone around me to clarify these querys. expecting all your replys and advanced thanks for the same, regards, s.subbarayan
  • 4. ata Compact flash & Windows compatibility
    I'm using an compact flash mapped as an ata device & running vxWorks 5.5. I would like to transfer files on a regular basis, between my target & windows based pc. in assumption that i don't want to write a special pc application and use the standard CF drivers, will i be able to copy dos files, and read them via vxWorks on the mpc8260 based target ? are there any known problematic issues: fat issues, format issues, etc... ? any options do i have, and what is the simplest way the acheive this goal ? any answer will be appreciated... ran.
  • 5. Routing without sending packet to ip stack ?
    My platform is using Tornado 2.0 and it is implemented for SOHO routing. I had finished testing that compare throughput with "brige" and "routing" mode. The throughput of brige mode is much better than routing mode. So I have an idea to maintain routing table by myself. But it needs much time. I don't know that any function that I can use to find correct route entry by destination ip address. Any suggestion? Thank you!

no-block socket problem, is this a vxWorks's bug?

Postby hill_liu » Tue, 28 Sep 2004 21:21:06 GMT


My term are developing a system about 3G'RNC. The hardware were made up of 
several SBC that compliant Compack PCI 2.16, echo SBC interconnect by 
TCP/IP. The problem is when a tcp client connect the server used a no-block 
socket and in this time the server have not run, the client side's connect 
function return a error "wouldblock",this is correct(accord BSD socket 
fashion), but subsequent calling of connect function return 0x16 for ever, 
even if the tcp server ran and correct listen a port to which the client 
connect. why?

thanks for any help.

Re: no-block socket problem, is this a vxWorks's bug?

Postby joe durusau » Thu, 30 Sep 2004 21:13:36 GMT

Can you clarify?  Are you saying that connect() is returning -1 and that
the lower 16 bits of errno are 0x16, or is connect() really returning 16 to
its caller??

Speaking only for myself,

Joe Durusau

Re: no-block socket problem, is this a vxWorks's bug?

Postby PeerSec Networks » Wed, 06 Oct 2004 02:27:27 GMT

Yes, we found similar bugs in non-blocking connect on VxWorks.  The API
would return an error code that did not reflect the reality of the
connection.  The workaround was to not use BSD compatible connect() API with
a non-blocking socket, but instead to use the VxWorks specific API,

 http://www.**--****.com/ #connectWithTimeout

In general, non-blocking connects must be handled differently between
VxWorks, UNIX and Windows.  It's one of the few areas of the Posix sockets
apis that aren't implemented cross platform in a standard way.

Also, be aware that on VxWorks, closing a socket that is being selected on
can corrupt the stack.  You must remove the socket from the select mask
before closing it!

Another socket error to avoid is closing the same file descriptor twice.
You shouldn't do this anyway, but on VxWorks, it can cause a seg fault.

Good luck!


Return to VxWorks


Who is online

Users browsing this forum: No registered users and 92 guest