code logs -> 2011 -> Thu, 24 Feb 2011< code.20110223.log - code.20110225.log >
--- Log opened Thu Feb 24 00:00:34 2011
00:11 AnnoDomini [annodomini@Nightstar-ead6d7da.adsl.tpnet.pl] has quit [[NS] Quit: Sleep.]
00:48 RichardBarrell_d [droid@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: Auf wiedersehen.]
01:02 Vornicus-Latens is now known as Vornicus
01:17 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?]
02:06 Attilla_ [Some.Dude@Nightstar-92c9199f.cable.virginmedia.com] has quit [[NS] Quit: ]
02:16 Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code
02:16 Stalker [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Client closed the connection]
02:29
< simon_>
anyone awake?
02:29
< simon_>
I'm looking for inspiration here.
02:29
< simon_>
I'm doing this exercise in my operating systems course
02:29
< simon_>
and I want to refactor some code here.
02:29 * Tamber hands simon_ the chainsaw.
02:29
< simon_>
;-)
02:31
< simon_>
I'm basically implementing user processes. the kernel doesn't support totally support them as it is delivered, but there are stubs of things in the thread_t structure that belong to processes.
02:31
< simon_>
-support
02:32
< simon_>
my idea of refactoring involves trying to move as many of these out of thread_t and into process_t because I want to be able to support many-to-one processes vs. kernel threads at some point (even though the assignment won't ask that of me, it'll be cleaner)
02:33 * Tamber paddles back to a level of conversation where $tamber->{brain} isn't drowning.
02:33
< simon_>
my question then is: thread_t involves a pointer to a pagetable_t, and as far as I can see, only the processes subsystem ever uses the pagetable. can I assume that pagetables are generally a userland service?
02:33
< Tamber>
I think I either need more caffeine, or more sleep. <.<
02:34
< simon_>
I slept for 15 hours. it's 3AM here, but I'm not at all sleepy. :)
02:34
< simon_>
I'm going to assume that pagetables are only used by userland processes.
02:35
< Tamber>
I can't remember when I last slept. Some time yesterday, I think. Might be a good idea to put down the emacs and step away from the keyboard, before I code anything else that's completely unintelligable.
02:36
< Tamber>
(My Perl's bad enough when I'm sober and awake!)
03:44 cpux is now known as shade_of_cpux
03:53
< Rhamphoryncus>
simon_: what's a user process?
03:53
< Rhamphoryncus>
and is this linux or something else?
03:55
< simon_>
sorry. this is "buenos", a toy kernel that I'm playing with.
03:55
< simon_>
it basically only has kernel threads to begin with, and I'm adding "processes"
03:55
< simon_>
currently they're only supposed to be one-to-one with kernel processes (which can also do other things than run user processes).
04:02 SmithKurosaki [smith@Nightstar-7820a96a.dsl.teksavvy.com] has quit [Ping timeout: 121 seconds]
04:07
< Rhamphoryncus>
ahh
04:09 SmithKurosaki [smith@Nightstar-7820a96a.dsl.teksavvy.com] has joined #code
04:23
< Rhamphoryncus>
I have a hard time suggesting anything other than "do what linux does"
04:25
< simon_>
Rhamphoryncus, what does linux do? ;)
04:26
< Rhamphoryncus>
no idea :D
04:26
< simon_>
I'll try and find out!
04:26
< simon_>
(I realized that asking OS questions is kind of like drawing pretty pictures, because apparently OSes do things very differently)
04:26
< Rhamphoryncus>
Well, I know it has an O(1) scheduler..
04:27
< Rhamphoryncus>
I'm really not sure what "kernel thread" means as opposed to just running stuff for a a process called into the kernel
04:28
< simon_>
a kernel thread consists of a control block with some context data about the thread (registers, links to virtual memory, etc.)
04:29
< Rhamphoryncus>
oh is this vs userspace threading?
04:29
< simon_>
well, yeah
04:29
< simon_>
there's kernel threads, user processes and user threads
04:29
< Rhamphoryncus>
ahhhh, makes much more sense now.
04:30
< simon_>
ok, cool
04:30
< Rhamphoryncus>
Linux abandoned userspace threads. Getting posix semantics right required kernel support and scheduling is faster directly in the kernel
04:31
< Rhamphoryncus>
the grey area, IMO, is when you experiment with extra semantics. Weird wakeup or preemption options for atomic ops, that sort of thing
04:32
< simon_>
so a pthread has kernel support, but a process in Linux isn't necessarily a pthread, is it?
04:33
< Rhamphoryncus>
Most of the scheduling is threads, but many APIs distinguish them. thread-ids are all per-process, as opposed to process-ids which are global
04:33
< Rhamphoryncus>
the API linux supports isn't limited to pthreads, but it basically is a posix thread or posix process
04:33
< Rhamphoryncus>
clone() and such let you do weird other things
04:36
< simon_>
clone sounds fun.
04:36
< Rhamphoryncus>
futexes let you mmap any shared bit of memory and have a bunch of threads from various processes waiting on them
04:38
< Rhamphoryncus>
if you want some history look for LinuxThreads, NGPT (next generation posix threads), and NPTL (native posix threading library). NPTL is now integrated into glibc (and the kernel of course)
04:40
< simon_>
thanks.
04:40
< Rhamphoryncus>
1 to 1 vs m-n threads is another related subject
04:41
< simon_>
yes
04:42
< simon_>
I'm going to make it work with one-to-one to begin with.
04:42
< Rhamphoryncus>
I'm very much a 1-1 proponent
04:43
< Rhamphoryncus>
m-n makes more sense when you have to work with an existing boundary. If you think about it, that's what qemu and other virtualizers (vmware) are doing
04:46
< Rhamphoryncus>
Even then you have to cross your fingers that the algorithms work sync up well. It's conceivable to have really bad interactions, which I'm sure is something they work around in practise
04:48 * simon_ thinks he will stick to one-to-one. ;)
04:48
< Rhamphoryncus>
:)
04:48 * Rhamphoryncus loves threading
04:49
< simon_>
I kind of like green threads.
04:49
< Rhamphoryncus>
What's your definition of green threads?
04:49
< simon_>
"how Erlang does it", or rather, with a thread context switch in userland.
04:51
< Rhamphoryncus>
as opposed to m-n?
04:54
< simon_>
not as opposed to anything... it just seems that you can get (green) thread context switches pretty fast, and that the advantage is that for some concurrency-oriented programming language, you don't need to integrate its runtime with the kernel.
04:55
< Rhamphoryncus>
That really is m-n threads
04:55
< simon_>
so, as opposed to kernel threads in general, I suppose. :) even though I've been playing with the idea of making a compiler for a little scripting language inside my buenos kernel, once I get a little more functionality done.
04:55
< simon_>
oh. I thought m-n meant m kernel threads, n processes
04:55
< Rhamphoryncus>
And yes, for a concurrent language with NO LIBRARIES you don't need kernel threads
04:56
< Rhamphoryncus>
m kernel threads mapping to n userspace threads
04:58
< Rhamphoryncus>
My ideal would be userspace hooks to preempt kernel switches. Just swap a pointer or two, the kernel will notice as soon as it wakes up
04:58
< Rhamphoryncus>
As well as having ways to do larger atomic ops, possibly via kernel rollbacks
04:59
< simon_>
yeah, I was thinking about that last thing.
04:59
< Rhamphoryncus>
I've read something about a microkernel doing userspace switches. Don't recall what one though
05:00
< Rhamphoryncus>
And there's lots of vague stuff about atomic ops these days.. nothing practical though
06:06 Kindamoody is now known as Kindamoody[zZz]
06:32 Derakon is now known as Derakon[AFK]
07:01 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
07:30 AnnoDomini [annodomini@Nightstar-ead6d7da.adsl.tpnet.pl] has joined #code
07:30 mode/#code [+o AnnoDomini] by Reiver
08:32 Vornicus is now known as Vornicus-Latens
09:04 Kindamoody[zZz] is now known as Kindamoody
09:08 * jerith boggles at a coworker.
09:13 You're now known as TheWatcher
09:16
<@jerith>
We're discussing an event distribution mechanism, and he thinks retaining backwards compatibility with his crappy single-purpose homebrew thing trumps the clean, robust solution two of us spent an afternoon designing.
09:29 SmithKurosaki [smith@Nightstar-7820a96a.dsl.teksavvy.com] has quit [Ping timeout: 121 seconds]
09:34
< simon_>
have you got a lot of code that needs the backwards-compatibility?
09:34
< simon_>
hmm... imagine. a programmer who doesn't want to do things from scratch for the sake of cleanliness. I have to restrict myself!
09:35
< simon_>
I already redid both of my weekly kernel assignments once each. >:)
09:35
< Serah>
Have you ever seen inside Sharepoint's codebase?
09:35
< simon_>
have I? no.
09:38
<@jerith>
simon_: One system. The new thing is replacing three different homebrew hacks that are all broken in different ways.
09:39 Kindamoody is now known as Kindamoody|out
09:40
<@jerith>
In general I'd agree with you, but in this case the "backwards compatibility" involves adding a lot of complexity to the system so he can avoid an hour or so of once-off programming effort.
09:41
<@jerith>
(Whereas the rest of us will have to spend longer than that implementing the horrible |-delimited prefix he wants to glue onto the front of the JSON message.)
09:42
< simon_>
well, you can't have anyone running around with a json parser parse your output, now can you!
09:43
<@jerith>
Quite.
09:43
< simon_>
don't you usually add metadata of json to the json data?
09:43
< simon_>
(guessing here. I tried to add comments in a json file, and the common way to do that, I found out, was to just add a _comment field that gets ignored)
09:44
<@jerith>
The other option he proposed was to push a bunch of the message metadata into the payload structure, thereby forcing the payload into a particular structure for no good reason.
09:44
< simon_>
(I guess that was just what I proposed, heh. what was your idea?)
09:45
<@jerith>
My idea was to have a JSON object with a small number of metadata fields and an opaque "payload" field.
09:45
<@jerith>
The only restriction on the payload is that a JSON parser doesn't barf on it.
09:47
<@McMartin>
Pardom my "it's almost 2 AM', but how is that different from option 2?
09:47
<@jerith>
Optio n2 pushes some of the metadata fields into the payload structure.
09:47
<@McMartin>
Aha
09:47
<@McMartin>
So, in your version, everything being sent is a single type
09:47
<@McMartin>
It's just that one of the fields is "arbitrary JSON thing"?
09:47
<@jerith>
Yes.
09:48
<@McMartin>
While in his, the arbitrary JSON thing gets those fields in it outright
09:48
<@jerith>
Yes.
09:48
<@jerith>
That's one compromise.
09:48
<@jerith>
The other compromise is to leave my format intact, but treat it as the payload in his |-delimited abomination.
09:49
<@McMartin>
Does JSON have a mechanism like Python to mark fields as "don't pay attention to this"?
09:49
< simon_>
json, jsoff.
09:49
<@jerith>
McMartin: Not that I know of.
09:50
<@jerith>
We're goign to be building and parsing these messages in Python and Java.
09:50
<@McMartin>
I'd go with "use weird field names for the metadata, strip them on the way out"
09:51
<@jerith>
McMartin: How's that better than having a thing wrapper around the message containing the metadata?
09:51
<@McMartin>
It might be politically feasible in this context.
09:51
<@McMartin>
That's really the sole advantage.
09:52
<@jerith>
If a solid technical solution is politically infeasible, my resignation will be on my boss' desk less than a minute after I'm told this.
09:52
<@jerith>
(It would be the final straw, more than anything else.)
09:54
<@McMartin>
(That said, I'm not up to speed on JSON or its interfaces. There may be technical reasons to prefer one or the other in terms of speed tuning or whatnot.)
09:55
<@jerith>
Nope, as far as I can tell it's so he can do his bit of bikeshedding.
09:55
<@McMartin>
The wrapper object is more guaranteed to be "correct" a priori; it may be up to twice as expensive an operation if object creation is costlier than field modification
09:55
<@jerith>
He cares deeply about making things fit into his existing hierarchy of POJOs and stuff.
09:56
<@McMartin>
If that's the case, your solution is better, becuase it has a POJO living there.
09:56
<@jerith>
Since no JavaScript is involved, JSON is nothing more than a serialisation format in our case.
09:56
< Namegduf>
JSON is a pretty nice serialisation format, though
09:57
< Namegduf>
Simple, reasonably small, and pleasant to read.
09:57
<@jerith>
It is a pretty nice serialisation format, which is why I like it.
09:57
<@jerith>
It's actually human-readable, unlike XML.
09:57
< Namegduf>
Yeah.
09:57
< Namegduf>
And human producable in a pinch if you just need a little for debugging.
09:57
< Namegduf>
I suppose XML is, too, but it's very annoying.
09:57
<@McMartin>
Depends on the document type/mechanic.
09:58
<@jerith>
McMartin: The payload is opaque, but it needs to be something that makes sense in a language-heterogeneous environment.
09:58 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code
09:59
<@McMartin>
I'm assuming it's some kind of key-value pair thing that will be turned into fields in an object and their initial values.
09:59
<@McMartin>
Am I way off base?
10:01
<@jerith>
It's an event notification system. The payload content depends very much on the type of event.
10:02
<@jerith>
I like simple JSON structures with the minimum of extraneous gumph.
10:02
<@McMartin>
Right, but I mean, when it's *deserialized*, what happens
10:03
< Namegduf>
Conversion into objects of the language, usually.
10:03
<@jerith>
Are you talking about the payload or the message wrapper?
10:03
< Namegduf>
JSON has key:value things, and arrays of values.
10:04
<@jerith>
We treat JSON as structures of dicts, lists and "primitive types".
10:04
<@jerith>
In Python-land, at least.
10:05
<@jerith>
It's more complicate in Java, because everything's more complicated in Java.
10:05
< Namegduf>
I was about to say much the same thing.
10:05
< Namegduf>
XD
10:13
< gnolam>
o/` Wer ist überall der Erste? Das ist Fritz, der Refaktorist! o/`
10:38 AnnoDomini [annodomini@Nightstar-ead6d7da.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds]
10:40 AnnoDomini [annodomini@Nightstar-946c50b0.adsl.tpnet.pl] has joined #code
10:40 mode/#code [+o AnnoDomini] by Reiver
10:57
<@jerith>
Am I the only person who finds test runs longer than a few seconds to be problematic?
11:03
<@jerith>
Ran 30 tests in 142.484s
11:03
<@jerith>
That's not even counting setup time.
11:15 * gnolam stabs Ubuntu's update manager.
11:33
< TheWatcher>
jerith: depends what the tests are doing!
11:35
<@jerith>
TheWatcher: If you're averaging nearly five seconds per test, you're doing something wrong.
11:43 RichardBarrell_d [droid@Nightstar-3b2c2db2.bethere.co.uk] has joined #code
11:43 RichardBarrell_d [droid@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: Auf wiedersehen.]
12:09 Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds]
12:49 Kindamoody|out [Kindamoody@Nightstar-4764665d.tbcn.telia.com] has quit [Ping timeout: 121 seconds]
13:53 Stalker [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code
14:17 Kindamoody [Kindamoody@Nightstar-787ffa7d.netlogon.liu.se] has joined #code
14:21 Kindamoody|out [Kindamoody@Nightstar-787ffa7d.netlogon.liu.se] has joined #code
14:31 Kindamoody is now known as Kimo|lab
14:34 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
16:34 Kimo|lab [Kindamoody@Nightstar-787ffa7d.netlogon.liu.se] has quit [Ping timeout: 121 seconds]
16:34 Kindamoody|out [Kindamoody@Nightstar-787ffa7d.netlogon.liu.se] has quit [Ping timeout: 121 seconds]
17:39 Kindamoody [Kindamoody@Nightstar-4764665d.tbcn.telia.com] has joined #code
17:44 Kindamoody|out [Kindamoody@Nightstar-4764665d.tbcn.telia.com] has joined #code
17:45 Kindamoody|out [Kindamoody@Nightstar-4764665d.tbcn.telia.com] has quit [Connection closed]
21:10 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has quit [Ping timeout: 121 seconds]
21:26 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has joined #code
23:07 AnnoDomini [annodomini@Nightstar-946c50b0.adsl.tpnet.pl] has quit [[NS] Quit: Zzz.]
23:07 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has quit [Client closed the connection]
23:13 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has joined #code
23:15 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has quit [[NS] Quit: ]
23:22 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has joined #code
23:29
< Alek>
welp, 7SP1 is out now.
23:29
< Alek>
now to see if it's installable. -_-
23:29
< Tamber>
Good luck.
23:29
<@McMartin>
I hear it doesn't work in VMware, but this is acknowledged as an issue with VMware
23:30
< Alek>
I'm updating 2 PCs simultaneously.
23:30
<@McMartin>
That shouldn't be a huge issue other than bandwidth wastage
23:30
< Alek>
and... it keeps failing out on the download.
23:30
< Alek>
and I have 2 more laptops to update later.
23:31
< Alek>
maybe I should see if I can grab the SP1 install from their website, instead of going through WU
23:32
<@McMartin>
Might be worth a shot
23:32
<@McMartin>
This is actually two days deferred, I note
23:32
<@McMartin>
IIRC official 7SP1 release was the 22nd
23:35
< Alek>
yeah, well.
23:35 * Alek eyes the computers.
23:36 Alek [omegaboot@Nightstar-96006922.il.comcast.net] has quit [[NS] Quit: be back later]
23:39 shade_of_cpux is now known as cpux
23:44
<@ToxicFrog>
Meanwhile, I'm trying to get the win7 pro copy my university provided installed, and move $HOME to another drive while I'm at it.
23:44
<@ToxicFrog>
I've gone from "hey, win7 isn't at all bad" to "I SHALL FEAST UPON MICROSOFT ENTRAILS THIS NIGHT" over the course of about an hour.
23:52
< Reiv>
Win7 is lovely.
23:52
< Reiv>
As long as you don't try to screw with things integral to the system... like where you keep $HOME. :p
23:53
<@ToxicFrog>
Except it's not integral to the system. That's kind of the point.
23:53 Rhamphoryncus [rhamph@C06FE3.F5723C.BE3FEB.9D4666] has quit [Client exited]
23:53
<@ToxicFrog>
I want to keep it elsewhere because it's not system data!
--- Log closed Fri Feb 25 00:00:35 2011
code logs -> 2011 -> Thu, 24 Feb 2011< code.20110223.log - code.20110225.log >