Arc Forumnew | comments | leaders | submitlogin
Confused by Arc threads
1 point by lacker 6097 days ago | 4 comments
One thing I constantly want to do is run some code, but have it time out in some way after n seconds. I'm having some trouble implementing this in Arc, though.

One confusing thing is that I can't figure out when the whole program exits. For example:

  (do (thread (sleep 2))
      (err "foo"))
This terminates the entire program after 2 seconds. Why?

In general, what is a nice way to communicate between threads? I feel like I am missing basic primitives in this area. Is ccc useful? It seems like I can't call a continuation made in another thread, but perhaps I am doing something wrong.



2 points by drcode 6096 days ago | link

I don't know of a nice way to communicate between threads... I also don't know of a way to do thread-specific storage (mzscheme has functions for both of these that are never lifted to arc)

However, you can relatively painlessly communicate between threads by using the atomic command- Just create a fun that can set/read a global variable based on a flag and have it use atomic to prevent simultaneous reading/writing. You can do a similar thing for thread-local storage (in a bit more complicated way)

There may be a better way to do this though- I'd love to hear what others have to say on this question...

-----

1 point by lacker 6096 days ago | link

What are these mzscheme functions you are referring to? I was just using a table keyed on thread for threadlocal storage. (Do I need to wrap table access in an atomic-invoke, by the way?)

I wish scheme documentation was more googleable. It's the opposite of javascript, in which you can find 100 ways to do anything, but they are all terribly ugly.

-----

2 points by drcode 6096 days ago | link

http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-7.h...

Actually, how did you manage to key on thread? I couldn't figure out how to do this myself, since there isn't a "thread id" or anything that would work as a key...

I would assume (but don't know for sure) that arc tables are thread-safe- I would think you didn't need to worry about atomicity, here...

-----

1 point by lacker 6096 days ago | link

Thanks for the pointer. Looks like tables are indeed threadsafe. From your link -

"The hash-table-put! procedure is not atomic, but the table is protected by a lock."

As far as threadlocal goes... new-thread returns the thread descriptor and you can use that directly as a hash key.

  arc> (= a (table))
  #hash()
  arc> (= (a (new-thread (fn () (sleep 10)))) 5)
  5
  arc> a
  #hash((#<thread> . 5))
This is inconvenient by itself since in arc you can't access the current thread descriptor without some trickery. It seemed easiest to expose mzscheme's current-thread. I imagine that will have to end up in arc eventually.

-----