[erlang-questions] multi-threaded woes

[Bob Cowdery]

Vlad

> you should implement your middle-tier in Erlang
I should, but its not trivial and I don't at the moment see why the C version is not working. That is my aim, I just didn't want to do it right now.

> So you have a working app, right?
The original build was one executable which was built with separation in mind. I then ripped it into two builds and linked the second in as a library. At this point no multi-threading was required as everything was synchronous call level. I then put Erlang in the middle and so far have failed to get it operational again. 

> go with regular sockets and Erlang-encoding of messages
I guess that's pretty close to what I have anyway except ei is abstacting the sockets layer a little.

> I think that it might be faster and easier to just do it in Erlang from the start
Erlang came along quite a way through the project. The intension is that the UI can be any language and might be fragmented across nodes and at the moment it seems that the UI needs to drive. I don't think there is a suitable Erlang binding to a GUI library such that Erlang can drive.

<[
the C implementation would possibly be an illustration of a paraphrase
of the classic Lisp quote: "any sufficiently advanced multithreaded
application contains a buggy implementation of an Erlang runtime"  :-)
]>
Well, yes, that seems to be a reason to use ei, unless you are saying that ei is not part of the Erlang runtime and may therefore be buggy!

Regards
Bob


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


Hi,

On 9/18/06, Bob Cowdery <Bob.Cowdery@REDACTED> wrote:
> 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.

No problem :-)

I don't have time right now to dig deeper, but the first impression is
that you should implement your middle-tier in Erlang, as it is there
you have paralellism and can harness the Erlang programming model.

> The UI then as far as I can see needs to be a C node and have separate client and server threads.

Yes, but those are only for handling the communications, right? And
each client talks only with the middle tier, right?

> 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.

So you have a working app, right?

If that is the case, the you should have the multithreading working
already. I think the simple way to implement a C-only proof of concept
is to go with regular sockets and Erlang-encoding of messages. C nodes
are really "handicapped" node, they lack a lot of the features of
Erlang nodes. Ei is just a communication layer, who lets a C program
masquerade as an Erlang node, but that's it.

If not, I think that it might be faster and easier to just do it in
Erlang from the start. You will have no advantage from implementing it
first in C.

<[
the C implementation would possibly be an illustration of a paraphrase
of the classic Lisp quote: "any sufficiently advanced multithreaded
application contains a buggy implementation of an Erlang runtime"  :-)
]>

Or maybe I misunderstood something ;-)
best regards,
Vlad