?

Log in

No account? Create an account
Dryice Update - The Desian Universe
Links Home / GitHub January 2017
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
 
 
 
deskitty
deskitty
Des
Thu, Jul. 8th, 2004 10:41 pm
Dryice Update

Damn, I am tired. Today was probably my most productive day so far this summer with Dryice.

>>> Progress Today

Most of the storage framework is now written, which means there will soon be an easy way to save and restore Dryice objects (including the bytecode which is generated by the compiler).

I also did a fair bit of work with the webpage, so there's a bit more information there now, including an outline/roadmap and a list of features I want the language to have.

>>> Musings about Object and Functional Models

So Dryice is (or will be) a weird mix of functional and object-oriented models. Functional models are good, especially in threaded programming, because they tend to assume most data structures are immutable. Immutable data structures are less complex code-wise and don't need locking (locking requires a lot of overhead). So Dryice's data structures will be as immutable as they can be, and I'll only allow changes (and do locking) where I really need to.

But I also like the object-oriented paradigm. My experience writing software so far has shown me that it's an incredibly powerful way to do things, and I don't think any modern language is complete without it. Hell, I'll admit it, OOP is central to my way of thinking about programs. ;)

The problem is, to be really useful, objects need to be mutable. (This certainly isn't true for all objects, but it is true for a non-trivial subset.) This is fine if you have proper locking in place for those that need it, but there is a danger that objects (I am speaking here of Dryice objects, not native C++ objects) may be touched by multiple threads before they are fully constructed. I don't think I need to explain why this is bad.

So my current dilemma is this: if Dryice constructors can execute arbitrary (byte)code (including spawning/touching other threads), how do I prevent other threads from getting hold of an object before it gets to a consistent state?

My intuition suggests there is only one solution to this problem ... collect all the object's data members (by calling its various constructors), and wait to create the object itself until the very last moment. But I guess we'll see how the details shake out in implementation.

-- Des

 22:41:22 up 1 day, 21:24,  3 users,  load average: 0.24, 0.06, 0.02

Current Mood: tired tired
Current Music: Sasha And John Digweed - Raincry - God Within

CommentReply