Fiber lifecycle - persistence

[GoogleCodeExporter]

Is it possible to move the 'definition of Executor' from 'Fiber constructor' to 
its start() method?

E.g.:
- create a fiber
- set up all my objects communicating over several channels
- fiber.start(new MyExecutor())
- //let my app run for a while
- fiber.stop()

I would like to persist all my objects to an object database (e.g. db4o) 
including all the channels set up between them. The problem is that creating a 
Fiber object already defines its backing executor and it is not 
serializable/persistable (not transient).

After I reload my objects from the database I would like them to be ready for 
use. Setting up the channels between them would be complex which I would like 
to avoid.

The problem would be solved if the Fiber lifecycle would allow a call like 
fiber.start(new MyExecutor())

Original issue reported on code.google.com by istvan.d...@gmail.com on 29 Oct 2010 at 4:51

[GoogleCodeExporter]

The Executor is specified at construction, so you can swap your own executor at 
construction.

Or provide your own Fiber implementation that does the persistence and 
delegates to the actual instance for functionality.

Fiber f = new MyPersistableFiber(new ThreadFiber());

Original comment by mike.ret...@gmail.com on 3 Nov 2010 at 2:33

• Changed state: WontFix
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Implementing an own fiber is possible, but that is more or less a 
reimplementation of your existing class(es).

I copied ThreadFiber renamed RestartableThreadFiber and got this one below. The 
only difference is that _thread/_scheduler are transient fields and created on 
call to start(). The stop method I do not need, I just added for symmetry.  
This change does not hurt the semantics so I think it might be included into 
the trunk. What do you think?

I'll look what needs to be done for PoolFiber.

Original comment by istvan.d...@gmail.com on 12 Nov 2010 at 5:23

Attachments:

• RestartableThreadFiber.java

[GoogleCodeExporter]

Serialization logic won't be added to the base ThreadFiber and related classes 
because it doesn't make sense unless the object can be rountripped (to/from 
bytes) while preserving behavior. What if the thread is already started? Your 
code works if the fiber is restarted every time. This creates extra maintenance 
for classes and IMO serialization doesn't really make sense for Fibers. Data 
objects should be serializable but not Threads/Fibers.

Original comment by mike.ret...@gmail.com on 12 Nov 2010 at 5:39