I'm trying to use a java library that itself uses tcp/ip to get some data. It returns the data on a different thread than the one where the request was invoked. Basically, I have no trouble either requesting the data or implementing the callback routine in Fantom that gets called when the data is available.

After looking at a number of Actor examples, I'm still a little confused. The question is, how do I notify my main "thread" that I'm done reading the data:

class Main {

static Void main() {
  dataInterface := DataInterface() // this is in external java library
  dataInterface.requestData()

  how to wait for data to be available?

}

//
// callback from Java library
// this is not on same Java thread as main
//
override Void dataAvaliable(Int i) {
  how to notify main thread?
}

I think the confusion is probably around the fact that the "main thread" isn't actually an actor who receives messages. So what you really want to do when your program starts up is launch the event receiver actor:

eventHandler := EventHandlerActor()
eventHandler.send(event1)
eventHandler.send(event2)
...

class EventHandlerActor : Actor
{
  Obj? receive(Obj? msg) { handle event }
}

So, you're suggesting my "main" routine be an actor? That makes things kind of difficult because of the lack of local state.

It seems to me the fwt model is much more of what I want, except I don't want Windows - just a console routine. How does fwt implement it's event loop?

As I recall, at one time, Fantom had some more "standard" thread routines. Or maybe you can just use the standard Java concurrent collections and Threads?

The FWT uses the SWT event loop, but that is essentially just all single threaded.

In Fantom, if you want to do multiple threads, you have to use actors. Under the covers there is thread pools and stuff but you operate a higher level of abstraction. And lack of state shared between threads is the entire foundation of Fantom's concurrency model. It may seem a bit weird coming from Java, but once you get used to it, it is a very simple way to reason about concurrency and is very robust.

So unless I don't understand your problem I still think what you want is to spawn your event handler as an actor. Then send it your events as messages - that is essentially is what an actor is: a thread who processes a queue of events/messages.