[00:00:25] <iceeey> was that a general question, or do you want to use exceptions for a specific thing?
[00:03:56] <thebolt> well, exceptions are a nice way of error reporting as they work "through" python ..
[00:11:57] <iceeey> yeah
[00:12:42] <iceeey> i was thinking we could have an exception for interrupting an action
[00:18:01] caedesX has joined #peragro-dev
[00:37:44] <sueastside> night
[00:38:57] sueastside has quit: "There will be a time when mankind can finally say that they've been on the moon!"
[01:11:50] Lightwave has joined #Peragro-Dev
[01:11:51] ChanServ sets mode: +v Lightwave
[01:38:39] caedesX changed nick to: caedes
[02:43:21] PK has quit: Read error: 60 (Operation timed out)
[03:50:28] ChanServ sets mode: +v caedes
[05:17:04] caedes has joined #peragro-dev
[05:17:04] ChanServ sets mode: +v caedes
[05:23:41] <iceeey> hi caedes
[05:27:22] iceeey has quit: Remote closed the connection
[11:41:05] sueastside has joined #peragro-dev
[11:41:05] ChanServ sets mode: +o sueastside
[12:35:04] caedes has joined #peragro-dev
[12:35:04] ChanServ sets mode: +v caedes
[12:40:40] <thebolt> hm, soom i have a small execution core running in stackless python, executing tasklets, rescheduling them, timed scheduling etc
[12:41:00] <sueastside> nice
[12:59:40] PK has joined #peragro-dev
[12:59:40] ChanServ sets mode: +o PK
[13:38:19] caedes_ has joined #peragro-dev
[13:38:19] ChanServ sets mode: +v caedes_
[15:08:40] PK has quit: "Leaving"
[16:08:19] caedes has joined #peragro-dev
[16:08:20] ChanServ sets mode: +v caedes
[16:29:12] PK has joined #peragro-dev
[16:29:12] ChanServ sets mode: +o PK
[16:51:55] PK_ has joined #peragro-dev
[16:51:56] ChanServ sets mode: +o PK_
[17:07:57] PK has quit: Read error: 110 (Connection timed out)
[18:07:22] <CyaNox> thebolt: is CS still supporting win9x versions?
[18:07:53] <thebolt> CyaNox: hm, technically i think most things are supported (ie the workarounds are still there), but we've decided not to continue to add such workarounds
[18:08:20] <CyaNox> that can be interpreted as not supporting win9x ... :p
[18:08:46] <thebolt> well, 1.0 should work on win9x, but we don't officially support it :)
[18:08:59] <thebolt> same way as it works on BSD, and appearantly SunOS, but we don't officially support it :9
[18:09:02] <thebolt> why?
[18:11:44] <CyaNox> well I was looking at http://www.buildaworld.net/page/wiki/ProjectHardwareRequirements and wanted to correct it a bit.
[18:14:29] <CyaNox> thebolt: http://www.buildaworld.net/page/wiki/ProjectRoadmap ... quite some incorrect data there aswell ... :p
[18:14:36] <CyaNox> PT aitn a port of CS ... :p
[18:18:12] <CyaNox> hhmmm well ... buildaworld might be a nice idea ... but I yet have to see if it is going somewhere.
[18:18:21] <CyaNox> Currently its only talk.
[18:23:16] <thebolt> :)
[18:23:28] <thebolt> btw, the first test running a stackless python execution core just ran
[18:23:38] <thebolt> cooperative multithreading
[18:23:46] <thebolt> time-schedulable tasks
[18:24:55] <CyaNox> does that work well on multicore CPU's?
[18:25:43] <CyaNox> or did I just ask the question that you would rather have not seen yet?
[18:31:42] <thebolt> well, it initself is single-threaded
[18:32:06] <thebolt> then you spawn separate worker threads for "long-running" things (as well as separate threads for things that can potentially block, such as sockets, DB IO, etc)
[18:34:05] <thebolt> the Eve game runs with a smiliar architecture, providing service for several thousand players per server
[18:37:38] <thebolt> did that answer your question satisfactory? ;)
[19:25:13] theboltEatingStu changed nick to: thebolt
[19:32:12] <CyaNox> yes it did
[19:32:41] <thebolt> you gain a lot of simplicity by actually having a mostly single-threaded model (as the coopeerative mt model is)
[19:33:05] <thebolt> you don't have to make sure simple stuff such as changing a property, spawning an entity etc are thread-safe in themselves
[19:33:36] <CyaNox> true but your still using multiple worker threads ... they need to be synchronous or not?
[19:34:37] <thebolt> well, depends on what the worker threads do
[19:35:02] <thebolt> for networking a worker thread is well-known.. basically one queue of packets to send and one of recieved packets (maybe (partially) decoded)
[19:35:24] <thebolt> for DB (for example) you can have similar concepts.. queue of data to write, and data requests (for reads)
[19:35:56] <thebolt> anohter example of where a worker thread can be of use is say weather simulation/erosion simulation or so, and there only the weather description component would interface it
[19:36:12] <thebolt> so the thread-safe part is highly confined and coupled with the component spawning the thread
[19:36:40] <CyaNox> hhhmmm so it is possible that locking can occur.
[19:37:16] <thebolt> well, depends on what you mean by locking
[19:37:24] <CyaNox> what happens if for some reason something request data from the database but the connection to the database was interupted?
[19:37:36] <thebolt> a tasklet should never block (and actually, if it does it will be killed)
[19:37:55] <CyaNox> nice
[19:37:55] <thebolt> however it can wait for a channel, which means that it will be taken out of scheduling until channel is signaled
[19:38:12] <thebolt> so say someone wants to access something in the db
[19:38:40] <thebolt> that tasklet would then create a channel, send a request to the db component where the db component queues a request for the DB thread and then waits for the channel to be signaled
[19:39:07] <thebolt> then there is another tasklet which is processing the "from DB queue" and wakes up tasklets when result comes back
[19:39:40] <thebolt> so the db thread takes requests from one queue, do operation and put them in another queue where the processing tasklet takes them and calls back to the originial source of the request
[19:40:09] <CyaNox> ah I get the picture
[19:41:04] <thebolt> and as we can detect run-away tasklets there is no chance of a full deadlock
[19:52:39] sueastside has quit: Read error: 104 (Connection reset by peer)
[19:52:56] sueastside has joined #peragro-dev
[19:52:57] ChanServ sets mode: +o sueastside
[21:19:28] LW|Asleep has joined #Peragro-Dev
[21:22:34] PK|Dinner has joined #peragro-dev
[21:22:35] ChanServ sets mode: +o PK|Dinner
[21:29:34] Lightwave has quit: Read error: 110 (Connection timed out)
[23:50:53] sueastside has quit: "<@Jorrit> docs? Is this actually documented?, In the manual?"
[23:54:47] iceeey has joined #peragro-dev
[23:54:48] ChanServ sets mode: +o iceeey
[23:59:29] <iceeey> hi