Hi Sérgio,
On Sun, 2011-07-24 at 18:08 -0400, Sérgio Capela wrote:
> Hi Peter,
>
....
> > If you have to have server-side discovery, you could only perform
> > inquiry with one controller at a time. That way, the other controller's
> > available for new rfcomm connections (assuming your client load-balances
> > like that...).
> >
>
> Yep, that is what I'm doing. I bind one adapter to the rfcomm server and
> use the other one for discovery and content delivery. The main process
> thread is the accept server and both the inquiry and the content delivery
> are done in threads launched for the purpose. I also made more tests
> recently and what is happening is that as soon as the inquiry starts the
> server stops accepting connections and starts processing inquiry result
> events, however, after a couple of minutes I can see the server both
> accepting and processing new connections and new inquiry result events.
> The end result is that launching an inquiry leads me to loose possible
> connections during a few minutes which is excessive for this case where
> inquiries would be launched regularly.
Inquiry in the host stack does serialize wrt. several other ioctl
functions; however, this is per device. Running a simple test here
produces expected results, ie. concurrent discovery and connections:
1. Start inquiry on device hci1. eg.,
hcitool -i hci1 inq --length=30
2. Initiate connection on device hci0. In my case, turning on a
bluetooth headset initiates a connection. Of course, the headset
was previously paired.
You may need to confirm where/what your threads are blocked on (well, at
least your main process thread that should be blocked on the accept
syscall). Stack backtrace in gdb would clear that up.
> >> Another question is related to a rfcomm client getting into D state and
> >> thus not killable.
...
> >
> > Although I'm not certain that they would fix the problem you're having,
> > I just posted a patch series that resolves some issues with lost wakeups
> > in rfcomm and l2cap. They need testing. You'd need patches 1~4 of 7.
> >
> > Please feel free to reply direct regarding whether you can test these
> > and what that outcome was.
>
> I suppose those patches would be available in the git sources right? At
> the moment I can't test it but in a week or two I will try to compile the
> sources and unless I encounter some problem I will reply in this topic.
Well, right now, those patches are on the mailing list. I was really
looking to get some more testing on them _prior_ to them making their
way into the kernel. They're mostly associated with missing wakeups --
although it's possible they could fix the D state client, I couldn't
hypothesize how the rfcomm socket could become uninterruptible from what
I fixed. They may be unrelated.
Regards,
Peter
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
