On Sat, Apr 26, 2008 at 10:33:45PM -0400, Colin J. Williams wrote:
> Could someone please remove
> my name from the mailing list?
You can always unsubscribe here:
http://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/
Oleg Broytmann wrote:
Interview with Donald Knuth:
http://www.informit.com/articles/printerfriendly.aspx?p=1193856&rll=1
Definitely very interesting by itself, but in the context of the
discussion the most interesting part is about parallel computing,
multithreading and multicore hardwar
Interview with Donald Knuth:
http://www.informit.com/articles/printerfriendly.aspx?p=1193856&rll=1
Definitely very interesting by itself, but in the context of the
discussion the most interesting part is about parallel computing,
multithreading and multicore hardware.
Oleg.
--
Oleg Broyt
Coroutines are safer for two reasons. The first is that synchronization is
in the programmer's head, while with threads and processes synchronization
is done by the operating system. With coroutines you have no deadlocks or
race conditions to worry about because you get to explicitly choose your
sy
Hallo,
Oleg Broytmann hat gesagt: // Oleg Broytmann wrote:
> On Mon, Apr 21, 2008 at 07:38:55PM +0200, Frank Barknecht wrote:
> > Coroutines are more lightweight than processes and don't need special
> > synchronisation efforts as only one Coroutine is running at any given
> > time.
>
> http://py
On Mon, Apr 21, 2008 at 07:38:55PM +0200, Frank Barknecht wrote:
> As I'm recently doing more Lua than Python programming: the Lua
> community is traditionally very sceptical of threads. The alternative
> approach generally taken in Lua are Coroutines, which found their way
> into Python some years
Hallo,
Oleg Broytmann hat gesagt: // Oleg Broytmann wrote:
> On Sat, Apr 19, 2008 at 11:19:14PM -0300, Carlos Ribeiro wrote:
> > But the fact is that today you have to deal with parallelism in one form or
> > another. It can be threads or multiple processes, it's unavoidable. And it
> > will get w
On Sun, Apr 20, 2008 at 09:45:28PM -0300, Carlos Ribeiro wrote:
> Threads are potentially much more
> efficient and faster than processes, but are so hard to get right.
They are faster at the cost of fragility. With the speed of hardware
constantly going up the cost becomes too big.
> Time to
The "problem" IMHO is with long running processes. Short-lived processes, in
the CGI (and now Google AppEngine) style, should have no problems. Long
running processes keep lots of data in memory, and keeping it in sync is
very hard. It can be nearly as hard as doing threads right. That was the
case
On Sat, Apr 19, 2008 at 11:19:14PM -0300, Carlos Ribeiro wrote:
> But the fact is that today you have to deal with parallelism in one form or
> another. It can be threads or multiple processes, it's unavoidable. And it
> will get worse with newer CPUs.
Threads are evil but processes are not - t
Oleg,
That's a rant, it's off topic, and I'm probably posting on the wrong forum,
but anyway.
I feel your pain, I've spent a good few hours this week debugging threaded
programs. At one point I found that I was using the same telnet instance on
two threads at the same time. No wonder things were
On Thu, Apr 17, 2008 at 04:03:08PM -0700, Fred C wrote:
> I was wandering if there is somewhere an sqlobject 101 for threading
> environment?
My personal position is: I avoid threads like a plague.
Other than that extreme position - SQLObject is mostly thread-safe,
there are people who su
I was wandering if there is somewhere an sqlobject 101 for threading
environment?
I have been googleing for infomation but everything seems confusing.
Thanks
-fred-
-
This SF.net email is sponsored by the 2008 JavaOne(SM)
13 matches
Mail list logo
