| Since I'm waiting for some parts for the prototype of a device I'm building, I'm currently sitting very bored in the office. So I decided to pull out some of my very old TO-DO lists on Arc. wiki in arc (done, but still needs polish), strings as lists (done, although somewhat hackish and definitely not very memory efficient), a method for creating user-defined collections (done, but effectively extends Anarki beyond plain Arc), improve HTML server (meh, trying to dig through srv.arc/app.arc/html.arc is a recipe for multiple personality disorder, I mean, look how many usernames kens now has ^^ LOL), Erlang-like concurrency (not done....) Huh. Anyway I thought of trying to figure out how to do a message passing shared-nothing process library in arc. And the first thing blocking me is: no blocking queue. arc.arc contains a definition for a queue, but there are some things we would like to have in the message queue: 1) reading from the queue should block the thread if it's empty. 2) we should be able to peek through messages (needed so that if we're currently waiting for a different message, we can just keep other messages we don't need yet in a queue) Now we can separate the queue into a queue and a mailbox. When checking for a message on the queue, first we check the mailbox, and if none matches our patterns, we wait on our queue. If we receive a message, again attempt to match patterns, and if it still doesn't match, attach it to the end of the mailbox. For other cases, pass the message. Of course, if we're waiting for a message, then it's probably better to block the current thread than to poll the queue. So I'm looking right now for a method to block a thread until it's notified that a new message has come. Probably this again means extending Anarki beyond pg's ArcN. Anyway I've been trying to research the underlying mzscheme's FIFO buffers. Creating a FIFO returns two values, an inport and an outport, and (I think, but not sure) it seems that reading from an inport will block if the FIFO is empty. Since message passing requires copying semantics anyway, it might be useful to serialize the data over the FIFO anyway (although definitely less efficient than just copying the original structure and passing it via some other method). Alternatively we could use the FIFO just as a sort of synchronizer: we provide some sort of resource-keeping structure, and send ID's via the FIFO; the receiver then gets the ID's and retrieves it from the resource keeper (which relinquishes its reference to it as soon as it is retrieved). Suggestions/recommendations of other methods of passing objects around in a thread-safe and thread-blocking manner would be nice. |
