[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] pipes for today
From: |
Krzysztof Kamieniecki |
Subject: |
Re: [Discuss-gnuradio] pipes for today |
Date: |
Wed, 20 Apr 2005 12:54:27 -0400 |
User-agent: |
Internet Messaging Program (IMP) 3.2.2 |
Eric,
Have you made any progress with this?
I'm having a problem that may be related. The blocks are layed out like this.
USRP Rx -> ... -> pipe
gr_sig_source -> ... -> USRP Tx
When running in gdb:
1. I wait for it to lockup
2. hit Ctrl-Z (to get into gdb)
3. type continue
4. more data is processed with a bunch of uU printed
5. software lockups again
6. goto 2
When I hit Ctrl-Z the Tx thread always seems to be in ioctl in _reap. Is this
normal?
Attached is a file with bt's for each of the threads
Thread 1 is Python/Wx, which seems to lockup
Thread 2 seems to be the USRP Tx graph
Thread 3 seems to be the USRP Rx graph
Thread 4 is my pipe monitoring thread, which does not lockup
Quoting Eric Blossom:
> On Fri, Apr 08, 2005 at 04:10:20PM -0400, cswiger wrote:
> > This is a curious behavior: if
> >
> > 1) Use a vector source at the head and the USRP at the tail all is OK
> >
> > 2) Use the pipe fd source at the head and a file sink at the tail all is
> > OK
> >
> > but if
> >
> > 3) Use a pipe fd source at the head and the USRP (with a parallel file
> > sink to monitor) at the tail data very slowly trickles into the file,
> > much slower than the 1.6Msps that it should - UNTIL I close the process
> > feeding the pipe, THEN it goes full blast and processes the backed up
> > pipe A-OK.
> >
> > very interesting ;)
>
> Chuck, if you send me the code to test example (3), I'll take a look at it.
>
> Eric
kkdeadlockinfo.txt
Description: Text document