Read-only image mode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Read-only image mode

Pavel Krivanek-3
Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.  It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel

Reply | Threaded
Open this post in threaded view
|

Re: Read-only image mode

Max Leske

Awesome! Thanks!

On 9 Jul 2019, at 14:28, Pavel Krivanek wrote:

Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.  It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel

Reply | Threaded
Open this post in threaded view
|

Re: Read-only image mode

ducasse
In reply to this post by Pavel Krivanek-3
This is cool to see this effort pushed again.
Thanks a lot Pavel. 

On 9 Jul 2019, at 14:28, Pavel Krivanek <[hidden email]> wrote:

Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.  It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Read-only image mode

ducasse
In reply to this post by Pavel Krivanek-3
Pavel 

I looked at your PR and I have some questions:
- could the fileReference have a class/instance var pointing to the store instead of having yet another
global access to a singleton like class :)

- I was wondering why you have macStore and unixStore and … 
I imagine to capture the difference but then why there is duplicated code
e.g. file: path uid: uidInteger gid: gidInteger looks the same

I hope that the class comment explains it :)

- Why do you have a class var for each store? and not one single metaclass inst var in the superclass?

Stef 


On 9 Jul 2019, at 14:28, Pavel Krivanek <[hidden email]> wrote:

Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.  It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Read-only image mode

Pavel Krivanek-3
Hi Stef,

út 9. 7. 2019 v 21:30 odesílatel ducasse <[hidden email]> napsal:
Pavel 

I looked at your PR and I have some questions:
- could the fileReference have a class/instance var pointing to the store instead of having yet another
global access to a singleton like class :)

 FileReference has inst. var pointing to a FileSystem that points to a Store. There is no global access from this perspective.
Of course, I tried to avoid making new globals as much as possible. The only exception if usage in File class because
it has very low level API that does not work with file references


- I was wondering why you have macStore and unixStore and … 
I imagine to capture the difference but then why there is duplicated code
e.g. file: path uid: uidInteger gid: gidInteger looks the same

The ideal solution here would be the Trait usage for read-only API but in Kernel it is not possible to use it. The current implementation
uses different strategies for every platform. For every one of them, I added a subclass for read-only strategy. They have the same
content (which is unfortunate implementation detail) but the strategy design here is definitely the way to go.
 

I hope that the class comment explains it :)

:-) I will improve it
 

- Why do you have a class var for each store? and not one single metaclass inst var in the superclass?

There are no class variables of Store classes. What do you mean, exactly?

-- Pavel
 

Stef 


On 9 Jul 2019, at 14:28, Pavel Krivanek <[hidden email]> wrote:

Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.  It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Read-only image mode

Pavel Krivanek-3
Hi Stef, 

you may download the built image from CI to see the code in the live image

-- Pavel

út 9. 7. 2019 v 23:13 odesílatel Pavel Krivanek <[hidden email]> napsal:
Hi Stef,

út 9. 7. 2019 v 21:30 odesílatel ducasse <[hidden email]> napsal:
Pavel 

I looked at your PR and I have some questions:
- could the fileReference have a class/instance var pointing to the store instead of having yet another
global access to a singleton like class :)

 FileReference has inst. var pointing to a FileSystem that points to a Store. There is no global access from this perspective.
Of course, I tried to avoid making new globals as much as possible. The only exception if usage in File class because
it has very low level API that does not work with file references


- I was wondering why you have macStore and unixStore and … 
I imagine to capture the difference but then why there is duplicated code
e.g. file: path uid: uidInteger gid: gidInteger looks the same

The ideal solution here would be the Trait usage for read-only API but in Kernel it is not possible to use it. The current implementation
uses different strategies for every platform. For every one of them, I added a subclass for read-only strategy. They have the same
content (which is unfortunate implementation detail) but the strategy design here is definitely the way to go.
 

I hope that the class comment explains it :)

:-) I will improve it
 

- Why do you have a class var for each store? and not one single metaclass inst var in the superclass?

There are no class variables of Store classes. What do you mean, exactly?

-- Pavel
 

Stef 


On 9 Jul 2019, at 14:28, Pavel Krivanek <[hidden email]> wrote:

Hi,

the current Pharo cannot deal very well in situations when you want to run multiple instances from one image file, especially on Windows, which complicates the setup of parallel applications.  It is not able to work reasonably on read-only file-systems too. That's why I did the next attempt to improve this functionality of the system.

In summary:
- the image can be executed with --readOnlyMode image argument
- the basic system tries to survive such limitation. The changes file is in read-only mode and new sources are installed into compiled methods directly, Ombu does not save content, Playground does not save cache etc.
- PharoDebug.log and placeholder files on Windows are not created
- the limitation is only on image-level so it is easy to bypass it.
- the presence of the old file streams makes everything uglier and messier

We have an open PR for this issue: https://github.com/pharo-project/pharo/pull/3837

Comments and reviews are welcome.

-- Pavel


Reply | Threaded
Open this post in threaded view
|

Re: Read-only image mode

ducasse
tx I will check. 

Stef


On 9 Jul 2019, at 23:15, Pavel Krivanek <[hidden email]> wrote: