Hello! In article <mailman.987965259.10112.python-list at python.org>, Gabriel Ambuehl <gabriel_ambuehl at buz.ch> wrote: >[...] >That's what I thought. As long as you aren't a good programmer able to >play with poll()/select() while a sleep, the whole network >programming, if it comes down to speed, is horrible to do. Dunno. For me, programming always new select() based main loops wasn't *too* difficult. However, after factoring out some common code in a C++ basis, writing reactive network servers got even easier, still without the overheads of pthreads. Of course, it's even neater to do that with a thread abstraction with a lightweight implementation, such as stackless python is supposed to be (or Erlang, or SML/NJ's CML implementation, or ...). >[...] >Threading in either C or C++ is a major PITA. Since the compiler >doesn't take complete care of the memory management, you can do >serious fuck ups with threads (and as we all know, buffer overflows >are common even in normal apps). That, and also, at least I like a message based threading model much more, however, I ran into major deadlocks when trying to do that in C/pthreads once, and rewrote it to do shared accesses on the data structures, protected by locks. Probably I've done too much Erlang lately *g* >[...] Kind regards, Hannah.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4