Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2009-12-11:

[3:44] <kikz4life> hi
[3:44] <kikz4life> hi to all
[3:44] <kikz4life> any1 here know flexigrid?
[3:47] <ashb> no
[3:47] <ashb> what is it?
[12:34] <chrisfarms> cool without ever seeing commonjs I seemed to have implimented 90% of securablemodules ... 10/10 for intuitive spec :)
[13:40] <Wes-> sembiance: ping
[14:11] <Sembiance> Wes-: PONG!
[14:28] <Sembiance> Wes: so, how are things going? :)
[14:29] <Wes-> Sembiance: totally awesome
[14:29] <Wes-> Writing lots of neat JS code, gpsee-core is starting to feel mature
[14:29] <Wes-> need more gpsee modules, though
[14:30] <Wes-> going to try and re-work binary/b implementation next week to do copy-on-write whenever possible
[14:30] <Wes-> Oh, did I tell you we have a workable FFI?
[14:30] <Sembiance> FFI?
[14:30] <Wes-> And we track the SUSv3 API for javascript-portable access to syscalls
[14:30] <Wes-> Sembiance: foreign-function-interface
[14:31] <Sembiance> ahhh cool, congo rats :)
[14:31] <Wes-> Yeah, FFI has been an interesting battle but it opens up a lot of doors
[14:31] <Wes-> The tricky part is balancing portability against functionality
[14:32] <Wes-> So far, we're erring on the side of portability under UNIX. Windows is a lost cause ATM (and probably forever)
[14:33] <Wes-> But I reasonably expect programs written with GPSEE to run on any modern UNIX, even with different architectures, different values for #define constants, different syscall struct layouts, etc, without special-casing anything in JS land
[14:33] <Wes-> which was tricky, because libc impls vary greatly
[14:33] <Sembiance> I can imagine :)
[14:33] <Wes-> We've had to do all kinds of crazy trampoline generation, dlsym() subversion and header-file parsing
[14:34] <Wes-> Good news is that non-libc interfaces tend to be much easier, as they are the same code base (e.g. libgd.so is the same on linux, apple, solaris)
[14:34] <Wes-> But libc interfaces are my focus right now, because we are writing base-level modules in JS + FFI
[14:35] <Sembiance> I totally hear you on needing more gpsee modules though. I have a bunch of projects in my head that I want to do. But I can't just "do them" in JavaScript because none of the server side javascript implementations have enough modules/API's yet. I really love JavaScript and want to do them there, but if I went and used Java (which I dislike as a language, but put up with) I could start implementing projects like right now.
[14:35] <Wes-> Binary/B COW is actually coming about because I want to be able to write my I/O streams with zero copies
[14:35] <Sembiance> so I'm waging this inner battle between growing the server side javascript infrastructure or working on more 'real' projects heh
[14:35] <Wes-> It's a tough battle
[14:35] <Sembiance> I wish I could flash forward 10 years or so
[14:35] <Wes-> I find myself reaching out to FFI more than encapsulating it, because I'm excited to make apps work :)
[14:36] <Sembiance> then I'm sure there would be great set of API support for numerous ssjs packages heh
[14:36] <Wes-> Yeah. I'm also hoping to do a decent job of wrapping non-gpsee jsapi packages soon, but the GPL is providing some headaches there
[14:38] <Wes-> I was pretty stoked, the other day, though
[14:38] <Wes-> I was writing an email gateway that did basic MIME parsing in JavaScript
[14:38] <Wes-> It went together *really* smoothly
[14:38] <Wes-> Then suddenly I found myself needing quoted-printable and base64 decoding
[14:39] <Wes-> I was able to use FFI to reach out to a DSO I wrote literally 10 years ago, pilfer the appropriate functions, apply them to my Binary/B ByteArray and continue yielding Binary/B ByteStrings to the parser
[14:40] <Wes-> It was just so awesome to get that kind of code reuse, never mind that JS objects are much better at representing MIME parts than C structs!!
[14:41] <Sembiance> hehe
[14:41] <Sembiance> yah, I love javascript :)
[14:43] <Sembiance> Wes-: gpsee is something your working on at work right? So your getting paid to work on this? That must be great. I have to write java code all day long for my day job :( only get to do fun JS stuff at home
[14:44] <Wes-> Sembiance: Indirectly. I have specific goals which are not "produce gpsee"; however, producing gpsee is an excellent side-effect
[14:45] <Wes-> Although my gpsee hacking time is really at a premium these days, sigh. So much paper to push, moronic web site changes to make, etc.
[14:46] <Wes-> Sembiance: Another fun idiom, we have built consume-and-yield pipelines
[14:46] <Wes-> we're still finalizing syntax, but expect something like this
[14:46] <Wes-> for (line in cay("cat /etc/pass")("grep wes")(jsFunction)) { print(line); }
[14:47] <Wes-> jsFunction is any function which is of the form
[14:47] <Wes-> jeepers, I've just drawn a blank on the syntax
[14:48] <Wes-> basically, it has to consume and yield, nominally ByteStrings be could be anything
[14:56] <Sembiance> hrm
[15:04] <Wes-> oh, I remember the syntax now for jsFunction, the first argument is a generator
[15:04] <Wes-> function(src) { for (line in src) { yield doWork(line); } }
[15:23] <ashb> Sembiance: what sort of libs do you need?
[15:24] <Sembiance> ashb: well, a good XML parsing API, something easy to use and yet powerful. XSLT transforms too. I have some projects that want to do some 3D work, so a higher level 3D API (above opengl). Java has a great one in jmonkeyengine. Some other things too :)
[15:27] <ashb> not much then :)
[15:27] <ashb> hippos has xml/DOM and could have xslt if i extended the bindings.
[15:28] <ashb> 3D is a tough one tho
[15:28] <Sembiance> aye
[15:28] <Sembiance> easpecially a 'higher level' one
[15:28] <Sembiance> because that means years of man effort gone into all the higher level code
[15:28] <Sembiance> I think I'm just out of luck on that part ;)
[15:31] <ashb> probably
[15:35] <Wes-> ashb: any thoughts as to what gpsee should have for a 0.2 release?
[15:36] <Wes-> I've got a build system, require, binary/b, FFI, CGI, will have fs-base, will have comment-embedded options
[15:37] <Wes-> oh, and of course, I have a couple of REPLs
[16:31] <ashb> Wes-: not sure
[16:31] <ashb> you probably have enough to warrant a release now
[16:31] <Wes-> ashb: *tough* innit?
[16:32] <Wes-> Was thinking first release might as well be something CommonJS-ily useful... I see binary, fs-base and of course require() there
[16:32] <Wes-> Should probably add system and module.id at least as well
[16:33] <ashb> system isn't hard
[16:33] <ashb> its argv, stdin/out/err
[16:33] <ashb> and umm, thats it?
[16:33] <Wes-> I think so
[16:33] <Wes-> I have a system object now which is something else
[16:34] <Wes-> this would be a good time to rename it
[16:34] <Wes-> stdin/stdout is a little trickier
[16:34] <Wes-> WTH are they? streams?
[16:35] <Wes-> Looking at the spec, I also don't understand why system contains "CGI environment variables"
[16:35] <Wes-> What does CGI have to do with it?
[16:35] <Sembiance> ugh. time to buy a new car :(
[16:35] <ondras> s/CGI // :}
[16:35] <ashb> Wes-: oh system.env
[16:36] <ashb> is just the normal environemtn
[16:36] <ashb> not sure why it says CGI
[16:42] <ashb> Wes-: your comment about timers/reactor strikes me as implementation detail
[16:43] <Wes-> ashb: not quite - presence of the comparison closure changes the implementation of setTimeout - or at least *should*
[16:44] <ashb> how so?
[16:44] <Wes-> my comment basically gives the event loop more understanding, what it can do with the understanding (priority) is an implementation detail
[16:45] <Wes-> ashb: if you want to write a setTimeout that sits on a reactor without a comparison closure, it needs to know that it must re-enqueue itself. However, if you implement *has* the comparison, re-enqueueing should not happen
[16:45] <ashb> implementation detail :) depends entierly on wether or not the event loop/eractor you use has native timers
[16:46] <Wes-> The key here is that you're more likely to be able to take advantage of the facility if it appears in the base spec -- note that the closure can just be "null"
[16:46] <Wes-> ashb: my thought is that timers are not the only thing which can take advantage of a "ready to run" closure
[16:47] <ashb> so where would you pass that closure to?
[16:47] <Wes-> anything which is of the onreadystate variety can
[16:47] <Wes-> ashb: when you enqueue the event
[16:47] <Wes-> then the event loop evaluates the closure, and does not run the event if it is not ready
[16:48] <Wes-> otherwise you have to run the event every pass through the loop, and the event has to be able to re-enqueue itself
[16:48] <ashb> thats bascially just moving the re-enque to a different level
[16:48] <Wes-> mechanically, yes, semantically, no
[16:48] <ashb> the same effect could be achieved by wrapping the event in a closure
[16:48] <ashb> i understand more what you mean
[16:48] <ashb> and it could be useful
[16:49] <Wes-> But that's the point - you *can't* achieve the same *semantic meaning* by wrapping the event in a closure
[16:49] <ashb> yes you can.
[16:49] <Wes-> and adding *meaning* instead of mechanics means that smart implementations can be smarter
[16:49] <ashb> either the reactor re-queues it, or the closure does it itself
[16:50] <Wes-> right, but the reactor can be smarter if it knows about re-enqueues, rather than seeing new events all the time
[16:50] <ashb> true
[16:50] <Wes-> never mind the fact that my guy tells me it's cheaper if the reactor re-uses the same closure instead of creating a new one on each pass of the loop
[16:50] <Wes-> s/guy/gut/
[16:50] <ashb> of course i would do a timer using that functionality cos it would be heavy on the CPU
[16:50] <Wes-> note: gut != measurement
[16:50] <ashb> but i can see it being useful
[16:51] <ashb> *woudldn't
[16:51] <Wes-> ashb: so you would use an OS timer to enqueue a now event?
[16:51] <ashb> i'd use a library :D
[16:51] <Wes-> (what I would do if I was implementing setTimeout FWIW)
[16:51] <Wes-> ashb: and the library would use an OS timer to enqueue a now event?
[16:51] <ashb> but if i was doing it 'natively'
[16:51] <ashb> i'd have a heap of timers
[16:52] <ashb> and check the time once per loop
[16:52] <ashb> and then run any timers tha have passed
[16:52] <ashb> (heap being the pririty based data structure)
[16:52] <Wes-> ashb: sounds a lot like enqueueing events with ready-to-run closures. ;)
[16:52] <Wes-> except that it would be a lot cheaper in native land
[16:52] <ashb> yeah
[16:53] <Wes-> But I also see onreadystatechange type events getting triggered that way too
[16:53] <Wes-> I think it would be cheaper to have a cheap "ready?" before de-queueing the event only to re-queue it 99% of the time
[16:54] <ashb> probably yes
[16:54] <ashb> it still smells a bit of implementation detail to me tho
[16:54] <Wes-> ashb: No, it's an API detail that affects implementation
[16:55] <ashb> i wonder why no other reactors have it
[16:55] <ashb> (at least none that i know of)
[16:55] <Wes-> ashb: beats me. Of course, I can think of one popular one that does, it's called "the unix kernel"
[16:57] <Wes-> and the unix kernel actually uses the information "was not ready, was not ready, was not ready" to affect priority. (affect priority == implementation detail)
[16:59] <Wes-> The other alternative for keeping the knowledge about is to have a re-enque-self API
[16:59] <Wes-> which I consider considerably less elegant
[17:00] <Wes-> ashb: do you any other popular reactor APIs?
[17:01] <ashb> so, POE (perl), EventMAchine (ruby), Twisted (python), libevent, libev, boost.asio
[17:01] <ashb> those aren't all strictly reactors mind
[17:01] <ashb> just async coding frameworks/libs
[17:01] <Wes-> I was just running through Twisted documentation
[17:02] <Wes-> it appears to use an implicit "am ready" based on whether a fd is usable according to select2)
[17:04] <ashb> actually uses select?
[17:05] <Wes-> it said something like "originally based on select(2)", actually
[17:06] <Wes-> but even select'ing across a field of fds is a million times better than running a million functions each of which poll a single fd
[17:06] <ashb> yeah
[17:07] <ashb> heh - speaking of priorities: http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/example/invocation/prioritised_handlers.cpp
[17:07] <ashb> yay for already written code!
[17:07] <Wes-> ashb: you could use that in an implementation detail with the API I'm suggesting -- make the
[17:08] <Wes-> "ready to run" be "does boost say it's ready to run"
[17:08] <Wes-> or, you could invert the control logic for something that's less general but faster
[17:08] <Wes-> have boost enqueue JS events
[17:09] <ashb> probably both. specal case known types
[17:09] <Wes-> *nod*
[17:09] <ashb> and have a generic cb for others
[17:13] <Wes-> Yeah. I remain convinced that specifying if (ev.check && (ev.check() !== false)) dispatchEvent(ev) is a general-purpose win for very small case
[17:14] <ashb> wonder if we should have a concept of 'loop time'
[17:14] <Wes-> for example, you could aggregate all your select() calls into one knowing that you had that in your event loop
[17:14] <ashb> i.e. a cached time at the start of the loop
[17:14] <ashb> (i know that libev has that for isntance)
[17:14] <Wes-> ashb: You actually don't need that if you schedule a recurring event that sets it
[17:14] <ashb> you know what. i think we should do a survey of those reactors mentioned
[17:14] <ashb> see what features they all have
[17:15] <Wes-> although it would be a sweet feature, I think
[17:15] <ashb> just as a general thing
[17:15] * Wes- nods
[17:15] <Wes-> my thoughts on that and select aggregation both point to recurring events (that run on each loop iteration) as necessary
[17:15] <Wes-> so, say, you wanted to aggregate selects
[17:15] <Wes-> you have a JS API which registers your interest in an fd
[17:16] <Wes-> and you have a recurring event that selects on all interesting fds
[17:16] <ashb> see i'd imagine that select (or similar) would be at the heart of most reactors
[17:16] <Wes-> then you eventDispatch comparison function checks if *that* fd is ready
[17:17] <Wes-> ashb: If we want file and socket centric reactors, that makes sense
[17:17] <Wes-> that would be the most effecient way of writing those
[17:17] <ashb> i spose a general purpose coop-threading reactor (Which is what POE is) doesn't strictly need it
[17:17] <Wes-> OTOH if we want a general-purpose reactor, what if your event doesn't get triggered by a file or socket?
[17:18] <Wes-> right
[17:18] <Wes-> I'm thinking that 'onclick' is a reasonable event to have
[17:18] <ashb> so asio at least has a 'post' event to schedule another event to be run imemediately
[17:18] <Wes-> exactly
[17:18] <Wes-> that's the same pattern I used for POSIX signals
[17:19] <ashb> well, fsvo 'immediately'
[17:19] <Wes-> the POSIX signal handler tells spidermonkey (via operation callback) to stop what's it's doing and run the event after the next opcode or branch
[17:19] <Wes-> in my case, the spidermonkey interpreter loop is the event loop
[17:20] <Wes-> so I get preemptive signal handling
[17:20] <ashb> op callback?
[17:20] <Wes-> but the concepts transfer
[17:20] <Wes-> ashb: yeah, are you familiar with it?
[17:20] <ashb> i get confused which is the new one and which is the old one
[17:20] <Wes-> JS_TriggerOperationCallback()
[17:20] <ashb> oh the op callback is the triggering one yeah
[17:25] <Wes-> yeah, used to be the branch callback triggered every time JS went backwards
[17:25] <Wes-> now the operation callback triggers after every interpreted opcode, or backwards JS branch
[17:26] <Wes-> the big deal, though, is that the branch callback kept a very expensive branch counter, which was a serious perf hit
[17:26] <Wes-> and almost completely superflous
[17:27] <Wes-> JS_TriggerOperationCallback() is also totally async-signal, MT safe. At least according to my analysis
[17:31] <Wes-> ashb: How do you use system.stdin?
[17:31] <Wes-> for (line in system.stdin) { print(line); }
[17:31] <Wes-> ?
[17:33] <ashb> dont think we have an interator
[17:33] <ashb> we have readLine method tho
[17:36] <Wes-> ashb: I'm trying to figure out what pattern to implement until streams exist.. iterators are easy, readLine, you call it like this?
[17:36] <Wes-> while (system.stdin.readLine()) { print(line); }
[17:36] <Wes-> ?
[17:36] <ashb> yeah
[17:36] <Wes-> I could just wrap fgets
[17:36] <ashb> line = system...
[17:36] <Wes-> oh yeah, lol
[17:50] <ashb> Wes-: i think brendan was talking about us:
[17:50] <ashb> 'who can hook into finalization or another GC phase do so for all the wrong reasons: to close fds, free database cursors'
[17:50] <Wes-> ashb: where talking?
[17:50] <Wes-> also, close fds not wrong imo!
[17:50] <ashb> doing it to tidy up is fine
[17:51] <ashb> so long as you know that when it will happen
[17:51] <ashb> Wes-: es-discuss in a thread about WeakPtrs
[17:51] <Wes-> sure can't leak fd's because programmer forgot to close!
[17:51] <Wes-> es-discuss is not behaviour right for me, sigh
[17:51] <Wes-> will have to read through the archives
[17:52] <ashb> in this case there isn't much more than is on the wiki
[18:08] <inimino> Wes-: nice looking stream API
[18:09] <Wes-> inimino: which one?
[18:10] <inimino> the ("cat passwd")("grep Wes") thing
[18:11] <ashb> yeah, i realyl like the 'this returnsa function idiom'
[18:11] <ashb> function chains ftw
[18:11] <inimino> I've seen that twice now recently
[18:12] <ashb> was the other one yesterday when i suggested it in #node.js?
[18:12] <ashb> (or maybe it was the day before)
[18:12] <inimino> no it was before that when I saw it in fab
[18:13] <ashb> fab?
[18:13] <inimino> yeah
[18:13] <ashb> whats that?
[18:13] <inimino> it's a router jed wrote for node
[18:14] <inimino> the ()()() syntax was the thing I found most interesting about it
[18:14] <ashb> ah
[18:14] <inimino> http://github.com/jed/fab
[18:14] <inimino> what did you suggest it for?
[18:15] <ashb> um, adding events i think
[18:15] <ashb> addEventListener("foo", foo)("bar", bar)
[18:15] <ashb> Listneres
[18:15] <Wes-> ashb: I just posted an event loop impl in JS for browser, could easily be adapted to run off another event loop (e.g. game, asio?)
[18:16] <inimino> ah
[18:16] <Wes-> inimino: Ah, thanks - it's very handy! hdon did the actual impl on that, significant portions are pure JavaScript
[18:16] <inimino> nice
[18:17] <ashb> Wes-: there is a need for 'loop indefinatly'
[18:17] <Wes-> what's not pure javascript is that it calls out to the shell when the argument is a string
[18:17] <Wes-> ashb: Yes
[18:17] <ashb> namely not hainvg to repeatedly cross the JS/native brdige
[18:17] <Wes-> ashb: Good point, the code I just posted does recurrance in the event loop which is in JS (but doesn't need to be)
[18:17] <inimino> Wes-: ah
[18:18] <Wes-> inimino: but the whole point was to make it easy to re-use existing shell tools, so it was the right choice. :)
[18:19] <inimino> ok :)
[18:21] <ashb> Wes-: okay so yeah, poll() and poll_one() are implementable that way
[18:21] <ashb> but the blocking versions aren't
[18:21] <ashb> (that way = in the browser)
[18:21] <Wes-> I don't think the reactor module should ever block
[18:22] <ashb> depends what you mean by block.
[18:22] <ashb> if you would otherwise have a while (!shutdown) { poll(); } loop
[18:22] <Wes-> block = do something indistinguishable from while(true)
[18:22] <ashb> then yes i think there should be an option to do that if it can
[18:23] <ashb> since it might well be able to do it a lot more efficently than calling poll() lots, and it will be a common use case on a server
[18:23] <Wes-> ashb: there's no need for it, it can be simulated with async (but not the other way around)
[18:23] <ashb> theres need and need. could we get by without it, yes
[18:23] <Wes-> no, on the server you should let the JS code "run out" before kicking off the event loop
[18:23] <Wes-> (assuming startEventloop() was called)
[18:24] <Wes-> I think even the browser works like that
[18:24] <ashb> i dont like that
[18:24] <Wes-> it finishes parsing your JS code etc before onmouseclick
[18:24] <ashb> it makes it very hard to make it just a module
[18:24] <ashb> needs deep ties into what ever engine it is running in
[18:24] <Wes-> ashb: *that's* true
[18:25] <Wes-> No, it needs a careful tie into whatever is calling JS_ExecuteScript()
[18:25] <Wes-> especially in your case, wanting to live under arbitrary event loops, this is important to think about
[18:27] <Wes-> I think a pretty key argument can be made though, that the basic thing that (flusspferd,gpsee,sproutcore) ties into for backing events might be (game,libev,browser)
[18:27] <Wes-> that's where the deep tie has to happen, and you have to finish executing JS code to give it proper control
[18:33] <ashb> Wes-: 'into whatever is calling JS_Exec' counts as deep ties into the engine
[18:33] <ashb> tho i guess i mean platform not engine
[18:33] <Wes-> right, and that's not going to happen in a module
[18:34] <Wes-> but it kinda makes sense
[18:34] <ashb> probably as an option
[18:34] <Wes-> if you want to embed flusspferd into a game, you don't want it blocking the game's event controller, you want it cooperating
[18:34] <ashb> // flussfperd: event-loop=zest/reactor
[18:34] <ashb> or something
[18:34] <ashb> absolutely - if its embeedded the game will ahve its own event loop
[18:35] <Wes-> right, so you want basically the browser semantics for that
[18:35] <ashb> er not at all.
[18:35] <ashb> its entierly up to the embedding
[18:35] <Wes-> yes, where you use the underlying event loop to schedule your own events
[18:35] <ashb> but in the case of a game the event loop is already running
[18:35] <ashb> and just calls back into JS things
[18:36] <Wes-> and one of those events is "look at the reactor module's event loop"
[18:36] <ashb> in that situation would imagine the game's event loop would *be* the reactor
[18:37] <Wes-> then the reactor module would be an interface to the reactor
[18:37] <Wes-> you still don't want javascript code pausing
[18:38] <ashb> sure, but you wouldn't have to do anything to call it
[18:38] <ashb> (i think we are basically furiously agreeing here, just comign from differnt sides)
[19:24] <ashb> Wes-: seen ryan's latest email?
[19:24] <ashb> you know posix quite well - you've got for signal handlers in process haven't you?
[19:24] <ashb> i guess doing them in a child process is safer as it abvoids interrupting syscalls?
[19:24] <Wes-> ashb: I have signal handlers in a separate thread
[19:24] <ashb> ah
[19:25] <Wes-> then that thread goes and triggers and operation callback on the context that registered the signal
[19:25] <ashb> so same idea as node, just a thread instead of a pipe
[19:30] <Wes-> well, thread instead of process, really
[19:31] <Wes-> he uses pipes so select() and friends can work
[19:31] <ashb> yeah
[19:31] <Wes-> wondering if he's got hammer-nail syndrome
[19:31] <ashb> i'd probably do iot the same way as you
[19:32] <ashb> espeically as reactor.post is thread safe
[19:32] <ashb> ooh infact http://old.nabble.com/extending-asio-with-unix-signal-handlers-td22595908.html
[19:32] <ashb> \o/ more free code!
[19:32] <Wes-> ashb: you don't want to use operation callbacks unless you want pre-emptive events (which I did for signals)
[19:33] <ashb> not sure if i want pre-empting signals or not
[19:33] <ashb> non-preempting is very easy using that code
[19:34] <Wes-> ashb: FWIW, you can build (approximately) non-preempting on top of preempting
[19:34] <Wes-> signal.onHUP = function() { enqueue(hupFunction); }
[19:34] <ashb> yeah. thats exactly what i was thinking of
[19:35] <Wes-> but, recall, you can't run jsapi code from a posix signal handler!!!
[19:35] <ashb> of course this all gets more complex if/when you have multiple JSContexts
[19:35] <ashb> but i'm not sure we're ever really going to do that
[19:36] <Wes-> ashb: FWIW, I'm moderately confident I am thread safe, async signal safe, and multiple-context safe in my impl
[19:36] <ashb> which context do signals get handled in?
[19:36] <Wes-> ashb: the context that registered the handler
[19:36] <ashb> ah. that makes sense
[19:36] <Wes-> also, I am mutex-less in that module, all CAS thin locks
[19:37] <ashb> CAS?
[19:37] <Wes-> compare and swap
[19:37] <ashb> ah
[19:37] <ashb> isn't that just another form of mutex?
[19:37] <Wes-> no, much cheaper, single hardware instruction
[19:37] <ashb> same principle tho isn't it?
[19:38] <ashb> what else does a mutex do on top?
[19:38] <Wes-> block, re-enter, but most importantly, call kernel space code
[19:42] <Wes-> should point out that I never spin
[19:44] <Wes-> http://bartoszmilewski.wordpress.com/2008/07/24/thin-locks-in-d/
[19:46] <ashb> i wonder what name i know CAS under
[19:46] <ashb> i've used it before
[19:46] <ashb> (at uni i had to write a kernel for a pentium like processor with (once i'd written the processor simulator))
[19:46] <ashb> that was a fun course
[19:47] <Wes-> ashb: ENTER_CRITICIAL_SECTION or somesuch under win32?
[19:47] <ashb> this would have been an asm-ish name
[19:47] <ashb> but only based losely on real asms
[19:48] <Wes-> CMPXCHG ?
[19:48] <ashb> might be yeah
[19:49] <ashb> Wes-: so CAS is just to stream line the quick case?
[19:49] <ashb> and you avoid spinning by using a normal OS mutex?
[19:49] <Wes-> ashb: except that I arrange the code so that there is no slow case
[19:49] <ashb> how?
[19:49] <Wes-> I never need to solve the problem of two threads trying to set the same signal handler at once
[19:50] <Wes-> either one thread wins or the other doesn't -- doesn't matter who
[19:51] <Wes-> I also use CAS techniques to enforce/mediate the lifecycle progression in my Thread class
[19:51] <Wes-> no mutexes there either
[19:51] <ashb> oh the CAS is in the setter
[19:51] <ashb> for some reason i thought it was in the handler
[19:52] <Wes-> no, yeah, CAS....CAS is kinda like pthread_mutex_trylock...pthread_mutex_unlock
[19:52] <Wes-> except that I can use it to set variables which indicate state machine state
[19:53] <Wes-> so state is actually enforced by cheap hardware instruction which also guarantees my access to the data
[19:53] <Wes-> guarantees/mediates whatever you want to call it
[20:00] <ashb> Wes-: CAS locks sounds cool. do you have to have a block of inline asm
[20:00] <Wes-> ashb: sort of, I stole the implementation from jslock.c a couple years back
[20:01] <ashb> ah
[20:01] <ashb> :)
[20:01] <ashb> jslock.c version has the mutex race too?
[20:01] <Wes-> same technique brendan uses for property access
[20:01] <ashb> (i.e. for the more generic slow case)
[20:01] <Wes-> mutex race?
[20:01] <Wes-> Oh
[20:01] <ashb> that article metions a case when you need to get a mutex
[20:02] <Wes-> There might be for his use-case, but there isn't always
[20:02] <Wes-> Not sure what brendan does
[20:02] <Wes-> He *does* use mutexes to implement on platforms without CAS
[20:02] <ashb> Wes-: ah - man 7 futex (on linux)
[20:06] <Wes-> scarily enough, spidermonkey also uses fcntl to implement js property locks on old-ass platforms
[20:06] <ashb> fcntl?!
[20:06] <Wes-> I shit thee not
[20:06] <Wes-> On platforms with no CAS and no threads
[20:07] <Wes-> the implementation for that hideousness is hidden in NSPR, in PRLock
[20:08] <Wes-> http://en.wikipedia.org/wiki/Compare-and-swap fwiw
[20:09] <Wes-> BTW I think it's possible to fast MT linked list insertion/deletion with CAS
[20:09] <Wes-> think: pretty sure, haven't tried
[20:37] <gmosx_> hello

 

 

Logs by date :