[hpsdr] cuSDR on Mac

[Hermann]

On Wed, Nov 7, 2012 at 1:14 PM, Jeremy McDermond <mcdermj at xenotropic.com>wrote:

>
> On Nov 7, 2012, at 12:26 AM, Hermann <hvh.net at gmail.com> wrote:
>
> >> QtUdpSocket really only wants to be owned and operated by a single
> thread so you really can't just send stuff willy nilly to it off of other
> threads, even though that may be thread safe around a mutex or something.
>  What really should happen is that a single object should hold the socket
> and do any sending/receiving that needs to happen on it.
> >>
> > OK, this questions my architecture at least for the use on Linux/MacOS.
> If you look in older versions of cusdr_HPSDRIO.cpp you will see that this
> class was intended to be the single object where all IO is done. I don't
> remember exactly what was the problem, but I do remember that I had
> problems in working with more than one HPSDR client in the LAN (I had two
> Metis and two Hermes running at the same time in my local network). My
> focus was always safe multi-threading, and now I have to learn that there
> is - so to speak -  another notion of 're-entrance' wrt sockets on Windows
> and Unix-like OSs Anyway, I will try to work out the necessary changes.
>
> I'm not sure how your internal architecture would affect what happened on
> the wire.  Were you trying to have a single instance of cuSDR talking to
> multiple HPSDR boxes?
>

No, or, not yet :-)  just find one HPSDR hardware at a time.

>
> > I think these issues can be solved. But still there are the questions on
> the overall GUI appearance/behavior of platform-independent code. We had
> this discussion earlier, and I very well remember your opinion on that,
> which I can understand very well. My first impression on my Linux box,
> although these were just very early steps into it, were very discouraging -
> not to talk about the OpenGL issues I saw.
>
> There are some OpenGL issues on resize, but that's all I saw on MacOS.  I
> think this issue is solvable, because I've seen it before with my MacOS
> code when I was doing something freaky in GL.
>

Probably the OpenGL implementation has far better supprt on MacOS than on
my Gentoo Linux, or at least, it is a little more cimplicated to have
initialied/installed correctly on Linux.

>
> I don't think this is a lost cause at all, and while everyone knows my
> position on cross-platform software I think it's worth having a good one
> out there for use.  The issue you're running into, IMHO, is that you're
> catching things that you probably shouldn't be doing on Windows that you're
> getting away with for various reasons.  They probably should be
> fixed/rearchitected not only from the perspective of cross-platform
> compliance, but also that it's probably the right thing to do.  For example
> in this particular issue, it may not be biting you on Windows now, but if
> your bind order changes just a little bit, you'll end up breaking the
> socket code on Windows too.
>

That might well be the case. As I said, I will work again on this
architecture and try to use only one socket in the one IO class.

>
> I have a busy day today, but let me see if I can do some work on the
> networking code.  I'm fairly experienced with it and am pretty happy with
> my Mac version, but I really went down to bare metal on that one.  It turns
> out that Apple's event-driven socket interface really isn't fast enough for
> what I want to do, so I went down to raw sockets.  I think that the
> QtUdpSocket interface is looking plenty fast, it just needs some
> restructuring in the way of the threading.  I can't test on Windows really,
> but I can send some patches back to you and see what you think.
>

That would be great. In fact, I've made good experience with my threading
architecture, it seems to be pretty stable and fast. Although it might look
that I'm rather generous with the number of threads I use.

73, Hermann
DL3HVH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20121107/b282723f/attachment-0004.htm>