Re: Getting an error display, vp_freepkt: Bad file descriptor.

On Mon, 11 Oct 2004 10:07:02 +0530, Prajith <[email protected]> wrote:
> Hi X.Tang,
> 
>  Thanks a lot for your detailed explanation about VPI. I respect and
> appreciate these efforts.
> 
>  In our code, as per the present design, we can't avoid using the VPI
> across the threads. Because,  in our code one thread is getting the packet
> from the Tcpip and putting it into the Queues, and the other thread is
> getting the packet from the Queues and send it back to the Tcpip. We will
> have to think over it for a solution.

QNX4 does not support real posix thread, that's why a lot of QNX4 library 
doesn't really handle exclusive access.

In your satuation, either you have to add a semaphore and let both your
thread lock it before calling VPI function, or create another Queue to let
your working thread return packets back. Something like this:

   VPI thread (vp_getpkt())  -->  queue for packets to process --> work thread
                                                                      
                                  |
   VPI thread (vp_putpkt())  -->  queue for packets to return   <-- work thread

Thus you can avoid the lock and have the VPI thread always do VPI calls.

-xtang

> 
> ----- Original Message -----
> From: Xiaodan Tang <[email protected]>
> To: <[email protected]>; Frank Liu <[email protected]>
> Sent: Friday, October 08, 2004 9:09 PM
> Subject: RE: [Openqnx-developer] Getting an error display, vp_freepkt: Bad
> file descriptor.
> 
> 
> 
> 
> > > -----Original Message-----
> > > From: Prajith [mailto:[email protected]]
> > > Subject: Re: [Openqnx-developer] Getting an error display,
> > > vp_freepkt: Bad file descriptor.
> > >
> > >  And I am not doing any fork() in my code.
> > >
> > > I am creating a thread in our code and using VPI library
> > > functions across the thread. ( I found, none of the VPI
> > > library functions are thread safe. Will this be the problem?)
> >
> > Hm...
> >
> > This is QNX4 right? So a "thread" is basically another vfork()
> > isn't it? (the new "thread" is just another process).
> >
> > Do you really HAVE TO create a "thread"? Can you make
> > it so that you only use one thread using VPI functions?
> > Something like:
> >
> >     int main() {
> >         crate_new_thread();
> >         vp_attach();
> >         ...
> >     }
> >
> > Make sure attach to VPI *AFTER* create thread, and the
> > new thread never call VPI function?
> >
> > > But I feel, once when I was doing a stress test on VPI
> > > using a program (without thread), I got he same error
> > > (vp_freepkt: Bad file descriptor.) If I get that program
> > > I will let u all know.
> >
> > That is also an interesting test to prove/denial our guess.
> >
> > >   BTW, what is this vp_freepkt() function? Can I get any
> > >   implementation document of the VPI?
> >
> > I don't think there is an "implementation document" ever
> > publiced, but let me explain the basic ideas behind VPI.
> >
> >
> > 1) The stack (Tcpip) allocate all it's buffers/clusters from a
> >     shared memory pool.
> >
> > 2) A VPI program will find out the pool, and map it into
> >     local virtual space.
> >
> > 3) The Tcpip Stack and the VPI program have "queues"
> >     in shared memroy, so they can exchange mbufs.
> >     VPI program use vp_getpkt()/vp_putpkt() to get/put
> >     mbufs on the queues.
> >
> > 4) The memory pool can only be operated by Tcpip.
> >
> >     So if a VPI program calling vp_mget*() try to get some
> >     memory, it actually turns into a Message send to
> >     Tcpip, saying "I want this much mbuf...".
> >
> >     When a VPI program calling vp_mfree() to free some
> >     mbufs, this also turns into a Message send to Tcpip,
> >     saying "these mbufs I can return to you..."
> >
> >     Of cause to minimize the message passing, the VPI
> >     program keep arround some free mbufs/mclusters
> >     and recycle them. Only if there is no more free mbufs
> >     locally during vp_mget*(), or there is too much free
> >     mbufs during vp_mfree(), then a message passing
> >     happened.
> >
> >     The internal function "vp_freepkt()" is the one to free
> >     mbufs back to Tcpip when vp_mfree() find there is
> >     too much free bufs locally.
> >
> > Hope this can give you some view of the VPI library.
> >
> > Regards,
> >
> > -xtang
> >
> 
>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl