[erlang-questions] multi-threaded woes

[Bob Cowdery]

Vlad

Sorry if this is a bit long and more information than you needed to know but I wnated to explain why I am doing what I am doing.
 
Eventually, this will be a distributed software radio with which many other people are involved. At the moment I am just testing the Erlang waters to see what can be achieved. I have only two units of compilation at the moment, a thin front-end which is GTK+ and a middle tier state machine which controls all the application logic and at the moment calls out directly to the other components of the system. Right now just about everything is in C. Once this is proven I expect to start adding pure Erlang nodes. I should be able to completely replace the middle tier with Erlang as well. 

The interaction between these two nodes is quite like an Ajax style web app. The GTK+ side has to be a C node because it needs to be an executable C program. Arguable the middle tier could be a C Port (not sure that helps) but right now is a C Node. The UI receives interactions from the user and sends an event message (with a little pertinent data) to the state machine. The state machine goes through its process and as a result constructs a single response message which is UI updates. The most complex of these is the start-up response which can be 46 separate updates packaged into one message. Now , if I just send these as a response to the request rather than a separate async message it won't work because some of those updates in turn generate events which nave responses, which of course kick right into the last response which is only part processed. In addition the UI can receive updates spontaineously from the state machine because some other node kicked it in a kind of remote-control fashion. 

The UI then as far as I can see needs to be a C node and have separate client and server threads. The state machine is debatable but I really wanted to get it working as is as it will probably have some major re-engineering later.

<snip>
An alternative approach (a little more Erlang-ish) would be to move
the connection handling to a proper Erlang node and let only that node
talk to the C node.

If you think this is feasible given the application can you give me a hint how it might operate because I'm having trouble visualizing the interactions.

If I was using plain C with sockets and say JSON for encoding I don't think I would have trouble with the two way connection, but then it would kinda defeat the object. I'm not sure what's going on in the ei library is my issue. I probably need to do a controlled test with minimal code to see what works but if anyone has already been there and knows the issues that would be nice.

Regards
Bob

-----Original Message-----
From: Vlad Dumitrescu [mailto:vladdu55@REDACTED]
Sent: 18 September 2006 10:00
To: Bob Cowdery
Cc: Erlang-Questions (E-mail)
Subject: Re: [erlang-questions] multi-threaded woes


On 9/18/06, Bob Cowdery <Bob.Cowdery@REDACTED> wrote:
> I am having some trouble getting two C nodes which are both clients and servers to connect both ways and not sure of the rules here.
   ...snip...
> I do need these nodes to be servers as multiple nodes will connect to them and I will need to spawn a thread for each.

Hi,

I don't know what kind of application you work on, so this may be way
off. Also, I hope I understood your question.

If you want to write C nodes that are multithreaded, you will have to
fight the same problems any multithreaded C application has and that
Erlang solves. C nodes are regular C programs, they can talk to Erlang
nodes but have no inherent better multithreading capabilities.

An alternative approach (a little more Erlang-ish) would be to move
the connection handling to a proper Erlang node and let only that node
talk to the C node. This way the C part will be single-threaded (but
maybe will have to be able to handle several sessions) and the messy
threaded stuff is handled on the Erlang side.

Hope this helps.
best regards,
Vlad