Jean-Paul Calderone wrote:
> On Fri, 15 Feb 2008 15:01:21 +0100, Thomas Boucher
> <thomas.boucher at student.ecp.fr> wrote:
>> Jean-Paul Calderone a écrit :
>>> Chris Armstrong's response to the post you refer to is accurate.
>>> Twisted
>>> APIs are not threadsafe. In order to call them from a thread other than
>>> the one in which the reactor is running, it is absolutely required
>>> that you
>>> use reactor.callFromThread. This is quite simple. Instead of:
>>>>>> proto.sendLine("line")
>>>>>> Simple do:
>>>>>> reactor.callFromThread(proto.sendLine, "line")
>>>>>> You will have to do this for every call you make to a Twisted API
>>> (except
>>> for reactor.callFromThread, of course ;).
>>>> I have just tried this method, and it perfectly works.
>> The twisted reactor is run in another thread and the calls to Twisted
>> are managed by the callFromThread method. The main advantage I see to
>> it (excepting the fact that it works) is that it does not require
>> changes in the way the graphic rendering is done : you do not care
>> about how python- ogre runs to code the twisted part.
>>> The best solution would be to really integrate the two loops. I
>>> don't know
>>> the details of OGRE though, so I can't tell you specifically how to
>>> do this.
>>> It is tightly dependent on the details of the loops being integrated.
>>>> What I can't see for the moment is how much better it would be to do
>> like the other ways delivered in the discussion thread (by Werner,
>> Bernie an Stefan). These ways consist in running Twisted first and in
>> letting it manage python-ogre (by doing the rendering frame by frame
>> with coiteration, or loopingcalls).
>> Is this better than doing separate threads ?
>> There are arguments about efficiency. Using threads has overhead which is
> not present when not using threads. These arguments are probably not very
> convincing in this case, since you would only have two threads and their
> overhead will be dwarfed by your rendering costs. You should be aware that
> reactor.callFromThread _does_ have some non-trivial overhead. Using it for
> each sendLine call _could_ have a noticable detrimental impact on your
> app's
> performance.
>> There are arguments about simplicity. It's harder to understand what a
> multithreaded program is doing. It's harder to debug a multithreaded
> program. It's very, very hard to unit test a multithreaded program. This
> is probably the compelling argument to try to avoid threads.
>>>> Because most other event loops are very bad at managing events. :)
>>> If you
>>> want reasonable network performance, you need a good network event
>>> loop to
>>> be in control.
>>>> Don't you think using basic sockets (easy to code in Python) to make
>> the network connection from a client to a server is more efficient
>> (considering the time spent to do it or the complexity of the code)
>> and more easy to keep in a project ?
>> That might be nice. However, almost without exception, the network code I
> read which does not use Twisted is buggy in the most trivial ways. It is
> rare for it to take more than a cursory glance to notice critical bugs
> (the sort which will result in data being lost). Of course, this doesn't
> mean that all network code written without Twisted is fatally flawed, but
> it does give me a reasonable basis to assume that it will have issues. :)
>> Twisted's APIs aren't just easier to use correctly than the BSD socket
> APIs,
> they're also consistent across platforms. Are you sure you know the BSD
> APIs well enough to write some that is correct on Linux and on Windows?
> (Let alone on OS X or FreeBSD) Even if you are, would you rather spend
> your
> time writing the error handling logic for each of these platforms or adding
> features to your game?
>> Twisted may seems to be harder than the socket module. It probably does
> have a higher up-front cost. However, in the long run, I think that you'll
> save yourself a lot of time using it rather than using sockets directly.
>> You also get the advantages which the structure Twisted attempts to impose
> on your application confers. For example, protocol/transport separation
> means that you can unit test your protocol implementation very easily. And
> that's assuming you even need to implement your own protocol, rather than
> using one of the protocols Twisted already includes an implementation of.
>> You also leave open the possibility of easily taking advantage of some
> other
> Twisted features which don't seem useful now but which you may benefit from
> later in development.
>> Hope this helps,
>
It certainly lists a goodly number of reasons why people should strongly
consider using Twisted, and there are a goodly number one doesn't come
across every day.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/