ocean-lang.org Git - ocean-D/blob - pony-thoughts

   1
   2 I just went to a talk about pony ... now I want to get back to ocean!
   3
   4 The main ideas were:
   5  - type "Capabilities" like shared/unshared/once/whatever
   6  - concurrency though message passing, not locks.
   7
   8 I need to think about the latter.  How does it scale.
   9 e.g. can it implement the sort of concurrency we use for the dcache.
  10 That includes fine-grained spinlocks and RCU.
  11
  12 I think that pony uses a separate thread(actors) to manage any
  13 shared/mutable object.  Messages are sent to the actor and they act.
  14
  15 That means one thread for each dentry??
  16 With coarse grained locking this might be good, like Hoare monitors.
  17 How would you model locks and RCU in this sort of language?
  18 control structure for holding the lock?
  19 Reference that is allowed to unlock?
  20
  21 RCU ?? read_lock is easy enough.  So this would be supported in
  22 the "runtime".  What would the language check?...
  23
  24 Certainly message passing is easier to work with.  If I was to
  25 provide that I would need a green-thread implementation.  This would
  26 need
  27  - non-blocking kernel APIs so thread can switch tasks instead of block
  28  - stack allocation.  For internal code we might be able to use a tiny
  29    stack and grow as needed.  For FFI a real stack allocation is
  30    important.  But FFI isn't task-aware so it can use thread stack.
  31    internal calls could be annotated with stack usage, calculated at
  32    link time - whether dynamic or not.  If a recursive function
  33    is called it has a preamble which allocates a dynamic stack.
  34
  35 Sending a message would queue for the task then try to take the lock and run.
  36 If lock isn't available, then when the lock is released, the next message
  37 will be dequeued.
  38
  39 Do we wait for a reply? If we did, we could deadlock.
  40 So have to wait for *any* message (including reply), and
  41 allow other messages to intervene.
  42 So if a monitor blocks waiting on a reply, then it must
  43 accept messages on oher threads??  That means different threads
  44 hold the 'same' lock.  Is that a good idea?  Probably not.
  45 So how is pony deadlock free?  It doesn't allow reply messages.
  46 So you cannot say "insert if not present".  You have to "insert, and
  47 call me back when done".