[Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost
Hi everyone. I want to announce the first (and *very* basic) version of Limbo. Limbo is a simple wrapper around NativeBoost that lets you run commands on the shell (via sh) or directly (no shell expansion). To use Limbo you will need the NBCog VM and install NativeBoost into your image (with "NBInstaller install"). You will also need to build the shared library from the archive attached to this e-mail and put it into the "Plugins" directory of the VM (instructions inside the archive). I also attached the xcode project. The Limbo repo: MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/Limbo' user: '' password: '' I am *not* an experienced C coder so there might be some horrible stuff in the box. If you have any suggestions / requests / bug reports or would like to contribute, let me know. Disclaimer: NativeBoost uses direct memory access. I have written Limbo to the best of my memory layout knowledge (I'm quite a n00b there) but cannot and will not guarantee that you might not experience memory leaks or VM crashes (or any type of crash for that matter). This is just a warning, I haven't had any troubles at all with Limbo so far. Cheers, Max
On 19 November 2012 17:17, Max Leske <maxleske@gmail.com> wrote:
Hi everyone.
I want to announce the first (and *very* basic) version of Limbo. Limbo is a simple wrapper around NativeBoost that lets you run commands on the shell (via sh) or directly (no shell expansion).
why you need to wrap around NativeBoost? perhaps a more correct phrasing would be 'using nativeboost'?
To use Limbo you will need the NBCog VM and install NativeBoost into your image (with "NBInstaller install"). You will also need to build the shared library from the archive attached to this e-mail and put it into the "Plugins" directory of the VM (instructions inside the archive). I also attached the xcode project.
The Limbo repo:
MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/Limbo' user: '' password: ''
I am *not* an experienced C coder so there might be some horrible stuff in the box. If you have any suggestions / requests / bug reports or would like to contribute, let me know.
Disclaimer: NativeBoost uses direct memory access. I have written Limbo to the best of my memory layout knowledge (I'm quite a n00b there) but cannot and will not guarantee that you might not experience memory leaks or VM crashes (or any type of crash for that matter). This is just a warning, I haven't had any troubles at all with Limbo so far.
Hmm.. what is the C part for? The whole idea of using NativeBoost is to avoid writing a single line of C code. Because if you cannot avoid that, writing a VM plugin turns to be more preferable. But i didn't saw your code yet, so just commenting what on surface :)
Cheers, Max
-- Best regards, Igor Stasenko.
On 19.11.2012, at 21:26, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 November 2012 17:17, Max Leske <maxleske@gmail.com> wrote:
Hi everyone.
I want to announce the first (and *very* basic) version of Limbo. Limbo is a simple wrapper around NativeBoost that lets you run commands on the shell (via sh) or directly (no shell expansion).
why you need to wrap around NativeBoost? perhaps a more correct phrasing would be 'using nativeboost'?
True. I chose "wrapper" with the idea that the NativeBoost part is hidden from the user. The user does not need to know how to use NativeBoost.
To use Limbo you will need the NBCog VM and install NativeBoost into your image (with "NBInstaller install"). You will also need to build the shared library from the archive attached to this e-mail and put it into the "Plugins" directory of the VM (instructions inside the archive). I also attached the xcode project.
The Limbo repo:
MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/Limbo' user: '' password: ''
I am *not* an experienced C coder so there might be some horrible stuff in the box. If you have any suggestions / requests / bug reports or would like to contribute, let me know.
Disclaimer: NativeBoost uses direct memory access. I have written Limbo to the best of my memory layout knowledge (I'm quite a n00b there) but cannot and will not guarantee that you might not experience memory leaks or VM crashes (or any type of crash for that matter). This is just a warning, I haven't had any troubles at all with Limbo so far.
Hmm.. what is the C part for? The whole idea of using NativeBoost is to avoid writing a single line of C code. Because if you cannot avoid that, writing a VM plugin turns to be more preferable. But i didn't saw your code yet, so just commenting what on surface :)
Very well possible that I got something wrong :) Anyway, I figured that it would be easier for me to write C than NativeBoost. Also, I use pipe / fork / execute, not sure how I would have done that in NativeBoost (although it's probably possible) :)
Cheers, Max
-- Best regards, Igor Stasenko.
On 19 November 2012 17:30, Max Leske <maxleske@gmail.com> wrote:
On 19.11.2012, at 21:26, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 November 2012 17:17, Max Leske <maxleske@gmail.com> wrote:
Hi everyone.
I want to announce the first (and *very* basic) version of Limbo. Limbo is a simple wrapper around NativeBoost that lets you run commands on the shell (via sh) or directly (no shell expansion).
why you need to wrap around NativeBoost? perhaps a more correct phrasing would be 'using nativeboost'?
True. I chose "wrapper" with the idea that the NativeBoost part is hidden from the user. The user does not need to know how to use NativeBoost.
To use Limbo you will need the NBCog VM and install NativeBoost into your image (with "NBInstaller install"). You will also need to build the shared library from the archive attached to this e-mail and put it into the "Plugins" directory of the VM (instructions inside the archive). I also attached the xcode project.
The Limbo repo:
MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/Limbo' user: '' password: ''
I am *not* an experienced C coder so there might be some horrible stuff in the box. If you have any suggestions / requests / bug reports or would like to contribute, let me know.
Disclaimer: NativeBoost uses direct memory access. I have written Limbo to the best of my memory layout knowledge (I'm quite a n00b there) but cannot and will not guarantee that you might not experience memory leaks or VM crashes (or any type of crash for that matter). This is just a warning, I haven't had any troubles at all with Limbo so far.
Hmm.. what is the C part for? The whole idea of using NativeBoost is to avoid writing a single line of C code. Because if you cannot avoid that, writing a VM plugin turns to be more preferable. But i didn't saw your code yet, so just commenting what on surface :)
Very well possible that I got something wrong :) Anyway, I figured that it would be easier for me to write C than NativeBoost. Also, I use pipe / fork / execute, not sure how I would have done that in NativeBoost (although it's probably possible) :)
Sure thing it is easier to use C functions from C code :) But then think that anyone who would like to use your stuff will need to build this library by himself, copy it to right place etc etc.. Which means, less work for you turns into more work for users. Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try. And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess. I am surely don't have good experience with this function to clearly tell if its usage is correct in context of VM or not. -- Best regards, Igor Stasenko.
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case. The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started). Dave
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know. Cheers, Max
Dave
I have run into a small problem with fork(): pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ] primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() ) Only the parent code is ever executed, #pid is never 0. Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer Any ideas? Cheers, Max On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer
Any ideas?
Cheers, Max
On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
-- Best regards, Igor Stasenko.
On 22.11.2012, at 12:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work: pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ] The file 'foo.log' is never created. The UnixOSProcessPlugin has pretty much the same code: ((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ] BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created).
Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer
Any ideas?
Cheers, Max
On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
-- Best regards, Igor Stasenko.
On Thu, Nov 22, 2012 at 04:04:00PM +0100, Max Leske wrote:
On 22.11.2012, at 12:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work:
pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ]
The file 'foo.log' is never created.
The UnixOSProcessPlugin has pretty much the same code:
((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ]
BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created).
Assuming that you are trying to do a fork followed by exec, you will want to do the exec immediately after the fork. This may introduce some complications when you do it as two FFI calls, because your child process is still running Smalltalk on the VM, and it needs to keep running long enough to the second FFI call. Opening a new file stream on 'foo.log' implies a *lot* of processing in the child VM, so I am not surprised that this does not work. You might try just making a little "hello world" C program, and see if you can exec that program after doing the fork. That would be a lot less processing for your child VM, so it may have a better chance of working. But you still may have a few issues to sort out in keeping the child VM running long enough to get the the exec FFI call. Dave
Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer
Any ideas?
Cheers, Max
On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
-- Best regards, Igor Stasenko.
On 22 November 2012 16:34, David T. Lewis <lewis@mail.msen.com> wrote:
On Thu, Nov 22, 2012 at 04:04:00PM +0100, Max Leske wrote:
On 22.11.2012, at 12:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work:
pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ]
The file 'foo.log' is never created.
The UnixOSProcessPlugin has pretty much the same code:
((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ]
BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created).
Assuming that you are trying to do a fork followed by exec, you will want to do the exec immediately after the fork. This may introduce some complications when you do it as two FFI calls, because your child process is still running Smalltalk on the VM, and it needs to keep running long enough to the second FFI call. Opening a new file stream on 'foo.log' implies a *lot* of processing in the child VM, so I am not surprised that this does not work.
You might try just making a little "hello world" C program, and see if you can exec that program after doing the fork. That would be a lot less processing for your child VM, so it may have a better chance of working. But you still may have a few issues to sort out in keeping the child VM running long enough to get the the exec FFI call.
aye... and with a bit of assembler black magic you can actually generate a code to call those two functions in same primitive, so you don't leave to interpreter at all. bit still it would be nice if it could work using two separate FFI calls.
Dave
Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer
Any ideas?
Cheers, Max
On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 22.11.2012, at 17:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 16:34, David T. Lewis <lewis@mail.msen.com> wrote:
On Thu, Nov 22, 2012 at 04:04:00PM +0100, Max Leske wrote:
On 22.11.2012, at 12:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work:
pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ]
The file 'foo.log' is never created.
The UnixOSProcessPlugin has pretty much the same code:
((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ]
BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created).
Assuming that you are trying to do a fork followed by exec,
That's the plan, although I'll have to do some stuff with the pipes before exec'ing.
you will want to do the exec immediately after the fork. This may introduce some complications when you do it as two FFI calls, because your child process is still running Smalltalk on the VM, and it needs to keep running long enough to the second FFI call. Opening a new file stream on 'foo.log' implies a *lot* of processing in the child VM, so I am not surprised that this does not work.
You might try just making a little "hello world" C program, and see if you can exec that program after doing the fork. That would be a lot less processing for your child VM, so it may have a better chance of working. But you still may have a few issues to sort out in keeping the child VM running long enough to get the the exec FFI call.
Ok. Not quite sure how that all works but I tried to come up with a program that is as short as possible: run | pid args | args := (LimboCommand new command: '/bin/echo'; arguments: { 'foo' }) primitiveArguments. pid := self primitiveRun. pid isZero ifTrue: [ self primitiveExecv: args first arguments: args ] ifFalse: [ "parent code" ]. Still not working. fork() does create the child process but it won't exec (because it never reaches that point in execution somehow) and I can't kill the child process on the command line (have to close the image; the childs are not zombies)
aye... and with a bit of assembler black magic you can actually generate a code to call those two functions in same primitive, so you don't leave to interpreter at all.
Cool :) Will be my last resort though. Regarding the "hanging" image: yes the child process is created but as the man page for fork() states that the parent will be suspended until the child is exec'ed. Therefore, having the image "hang" is expected because I can't exec the child. Thanks for the help guys. Max
bit still it would be nice if it could work using two separate FFI calls.
Dave
Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer
Any ideas?
Cheers, Max
On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I did some more digging and I found that I was wrong before: every child process I create through NB is killed immediately and becomes a zombie (that's why it ignored the kill). Once I had that information I implemented the waitpid() call and can now cleanup my zombie children. This would also explain (at least to my mind) why the child code (pid = 0 ifTrue: [ ⦠]) is never executed. Now, my question is, who terminates my child processes? The processes are terminated with SIGABRT; all of the above also applies to vfork(). I found that there's a crash report being generated for that aborted process so I'm attaching it here, maybe you'll see something I missed. Max Process: NBCog [36367] Path: /Users/USER/*/NBCog.app/Contents/MacOS/NBCog Identifier: NBCog Version: NBCog VM 6.0-pre (21.0) Code Type: X86 (Native) Parent Process: NBCog [36341] User ID: 501 Date/Time: 2012-11-23 16:17:42.083 +0100 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Application Specific Information: *** multi-threaded process forked *** abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x94ce33ba __kill + 10 1 libsystem_kernel.dylib 0x94ce24bc kill$UNIX2003 + 32 2 libsystem_c.dylib 0x91df4527 abort + 215 3 org.squeakfoundation.Squeak 0x0008ab6f error + 95 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x0008ab1a ecx: 0xbff5cb0c edx: 0x94ce33ba edi: 0x91df445d esi: 0xbff5cb44 ebp: 0xbff5cb28 esp: 0xbff5cb0c ss: 0x00000023 efl: 0x00000282 eip: 0x94ce33ba cs: 0x0000000b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0xac30602c Logical CPU: 0 Binary Images: 0x1000 - 0x15ffe7 +org.squeakfoundation.Squeak (NBCog VM 6.0-pre - 21.0) <EAE0D546-1F67-0322-08AA-51D4BCF1AC58> /Users/USER/*/NBCog.app/Contents/MacOS/NBCog 0x425000 - 0x432ff3 com.apple.Librarian (1.1 - 1) <88A55A5E-40FF-3234-8394-2317120B79AB> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian 0x4e1000 - 0x4e6fff com.apple.audio.AppleHDAHALPlugIn (2.3.1 - 2.3.1f2) <58BDA15D-2B2D-3E77-BC8C-D14AB1E4AC4E> /System/Library/Extensions/AppleHDA.kext/Contents/PlugIns/AppleHDAHALPlugIn.bundle/Contents/MacOS/AppleHDAHALPlugIn 0x7f6000 - 0x7f8fff libCoreFSCache.dylib (24.4) <A089ED2E-0156-3937-BE32-5BED76DF4066> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib 0x1fe7000 - 0x1fefffc libcldcpuengine.dylib (2.1.19) <E5429AB3-FE28-3C0C-8942-686BB4191A9E> /System/Library/Frameworks/OpenCL.framework/Libraries/libcldcpuengine.dylib 0x1ff6000 - 0x1ff6ff7 +cl_kernels (???) <64C17F28-0A2C-453B-87E7-E8F93E3D491B> cl_kernels 0x1ffb000 - 0x1ffcffd +cl_kernels (???) <557FD908-32E8-4B19-A750-89261585E289> cl_kernels 0x47ba000 - 0x47bcff7 +libLocalePlugin.dylib (0) <493B55FB-A239-B7B9-F65B-345BC0934A06> /Users/USER/*/NBCog.app/Contents/MacOS/Plugins/libLocalePlugin.dylib 0x6c17000 - 0x6ca9ff7 unorm8_bgra.dylib (2.1.19) <A2C66114-F581-3D86-9BC9-9994156640AF> /System/Library/Frameworks/OpenCL.framework/Libraries/ImageFormats/unorm8_bgra.dylib 0x70000000 - 0x7015dff7 com.apple.audio.units.Components (1.8 - 1.8) <2637680C-A07E-3387-BD21-33B04B7C7A95> /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio 0x8fe0f000 - 0x8fe41e57 dyld (210.2.3) <23516BE4-29BE-350C-91C9-F36E7999F0F1> /usr/lib/dyld 0x90007000 - 0x90008fff libquarantine.dylib (52) <D526310F-DC77-37EA-8F5F-83928EFA3262> /usr/lib/system/libquarantine.dylib 0x90009000 - 0x90032fff libxslt.1.dylib (11.3) <0DE17DAA-66FF-3195-AADB-347BEB5E2EFA> /usr/lib/libxslt.1.dylib 0x90033000 - 0x90053ffd com.apple.ChunkingLibrary (2.0 - 133.2) <FE5F0F1E-B15D-3F76-8655-DC2FE19BF56E> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x90054000 - 0x900f4ff7 com.apple.QD (3.42 - 285) <1B8307C6-AFA8-312E-BA5B-679070EF2CA1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x900f5000 - 0x90122ffe libsystem_m.dylib (3022.6) <9975D9C3-3B71-38E3-AA21-C5C5F9D9C431> /usr/lib/system/libsystem_m.dylib 0x90123000 - 0x90565fff com.apple.CoreGraphics (1.600.0 - 324.6) <66556166-F9A7-3EEC-A562-46061C7A79E4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x905fe000 - 0x90683ff7 com.apple.SearchKit (1.4.0 - 1.4.0) <454E950F-291C-3E95-8F35-05CA0AD6B327> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x90684000 - 0x906a1fff libxpc.dylib (140.41) <1BFE3149-C242-3A77-9729-B00DEDC8CCF2> /usr/lib/system/libxpc.dylib 0x906a2000 - 0x9090ffff com.apple.imageKit (2.2 - 667) <3F5F92DB-C0C0-3C5F-98C6-B84AB9E28B55> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/ImageKit 0x90910000 - 0x90934fff com.apple.PerformanceAnalysis (1.16 - 16) <18DE0F9F-1264-394D-AC56-6B2A1771DFBE> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x90935000 - 0x909b1ff3 com.apple.Metadata (10.7.0 - 707.3) <6B6A6216-23D0-34CE-8099-BEE9BA42501E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x909b2000 - 0x909f7ff5 com.apple.opencl (2.1.20 - 2.1.20) <41C4AE6E-67B6-33E2-A9B6-BF6F01580B16> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x915ee000 - 0x915f7ff9 com.apple.CommonAuth (3.0 - 2.0) <A1A6CC3D-AA88-3519-A305-9B5D76C5D63B> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x915f8000 - 0x915fcfff com.apple.OpenDirectory (10.8 - 151.10) <A1858D81-086F-3BF5-87E3-9B70409FFDF6> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x915fd000 - 0x9182dfff com.apple.QuartzComposer (5.1 - 284) <4E8682B7-EBAE-3C40-ABDB-8705EC7952BD> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/Versions/A/QuartzComposer 0x9182e000 - 0x91bc1ffb com.apple.MediaToolbox (1.0 - 926.62) <7290B07B-4D03-3B46-809C-64C8FB97B40C> /System/Library/Frameworks/MediaToolbox.framework/Versions/A/MediaToolbox 0x91bc2000 - 0x91c10ffb libFontRegistry.dylib (100) <3B8350C2-4D8F-38C4-A22E-2F855D7E83D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x91c11000 - 0x91d1eff3 com.apple.ImageIO.framework (3.2.0 - 845) <BF959BCB-C30A-3680-B7C2-91B327B2B63B> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x91d95000 - 0x91d9ffff libsystem_notify.dylib (98.5) <7EEE9475-18F8-3099-B0ED-23A3E528ABE0> /usr/lib/system/libsystem_notify.dylib 0x91da6000 - 0x91e63feb libsystem_c.dylib (825.25) <B1F6916A-F558-38B5-A18C-D9733625FDC9> /usr/lib/system/libsystem_c.dylib 0x91e64000 - 0x91e7afff com.apple.CFOpenDirectory (10.8 - 151.10) <56C3F276-BD1F-3031-8CF9-8F4F481A534E> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x92108000 - 0x92157ff6 libTIFF.dylib (845) <989A2EB9-3A49-3157-8E9C-B16E6005BC64> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x92158000 - 0x921b3fff com.apple.htmlrendering (77 - 1.1.4) <5C0C669F-AE07-3983-B38F-EB829B5CE609> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x921b4000 - 0x9225efff com.apple.LaunchServices (539.7 - 539.7) <AF33EBD3-BC0B-30B5-B7DA-5CCCF12D7EDD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x9225f000 - 0x922adff3 com.apple.SystemConfiguration (1.12.2 - 1.12.2) <7BA6C58B-0357-356F-BB69-17ACB5E35988> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x922ae000 - 0x922b6fff libcopyfile.dylib (89) <4963541B-0254-371B-B29A-B6806888949B> /usr/lib/system/libcopyfile.dylib 0x922b7000 - 0x92398fff libcrypto.0.9.8.dylib (47) <D4EFFCFB-206D-3E3D-ADB5-CBAF04EB8838> /usr/lib/libcrypto.0.9.8.dylib 0x92399000 - 0x923e2ff7 com.apple.framework.CoreWLAN (3.0.1 - 301.11) <ABA6A926-34C2-3C09-AD9F-A87A8A35536A> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN 0x9242f000 - 0x9252dff7 libFontParser.dylib (84.5) <B3006327-7B2D-3966-A56A-BD85F1D71641> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x9252e000 - 0x92531ff9 libCGXType.A.dylib (324.6) <3004616B-51F6-3B9D-8B85-DCCA3DF9BC10> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib 0x92532000 - 0x92626ff3 com.apple.QuickLookUIFramework (4.0 - 555.4) <D66F61A6-2C4C-359F-A2E3-7D023C33CB5A> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/QuickLookUI 0x92627000 - 0x92637ff7 libsasl2.2.dylib (166) <D9080BA2-A365-351E-9FF2-7E0D4E8B1339> /usr/lib/libsasl2.2.dylib 0x92638000 - 0x931f4ffb com.apple.AppKit (6.8 - 1187.34) <06EDB1D1-3B8A-3699-8E3A-D8F50A27AB7C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x931f5000 - 0x93207fff libbsm.0.dylib (32) <DADD385E-FE53-3458-94FB-E316A6345108> /usr/lib/libbsm.0.dylib 0x93208000 - 0x932a2fff com.apple.CoreSymbolication (3.0 - 87) <6A27BBE5-6EF0-3D5D-A485-2145826B9796> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x932a3000 - 0x93563fff com.apple.security (7.0 - 55179.1) <CB470E48-621B-34D9-9E78-8B773358CB6B> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x93564000 - 0x9391cffa libLAPACK.dylib (1073.4) <9A6E5EAD-F2F2-3D5C-B655-2B536DB477F2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x9391d000 - 0x9395fff7 libauto.dylib (185.1) <B2B5B639-6778-352A-828D-FD8B64A3E8B3> /usr/lib/libauto.dylib 0x93960000 - 0x939bbff7 com.apple.AppleVAFramework (5.0.18 - 5.0.18) <4BA2AAEA-4936-375C-B4D8-4BBE2EDC7FF5> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA 0x939bc000 - 0x93a7aff3 com.apple.ColorSync (4.8.0 - 4.8.0) <EFEDCB37-4F20-3CEC-A185-5D2976E11BAC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x93a7d000 - 0x93ac1fff libGLU.dylib (8.6.1) <06BAFDCA-800C-35E3-B1A3-F05E105B86AB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x93ac2000 - 0x93ac6ffe libcache.dylib (57) <834FDCA7-FE3B-33CC-A12A-E11E202477EC> /usr/lib/system/libcache.dylib 0x93ac9000 - 0x93ae8ff3 com.apple.Ubiquity (1.2 - 243.10) <D2C9F356-1681-31D2-B292-5227E2DDEB0B> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity 0x93ae9000 - 0x93cd1ff3 com.apple.CoreFoundation (6.8 - 744.12) <E939CEA0-493C-3233-9983-5070981BB350> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x93cd2000 - 0x93e2affb com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <9205DFC2-8DAE-354E-AD87-46E229B5F2F1> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x93e2b000 - 0x93e34ff3 com.apple.DisplayServicesFW (2.6.1 - 353) <50D0BBF0-F911-380F-B470-E59B5E48E520> /System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices 0x93e35000 - 0x93f26ffc libiconv.2.dylib (34) <B096A9B7-83A6-31B3-8D2F-87D91910BF4C> /usr/lib/libiconv.2.dylib 0x93f27000 - 0x93f2aff7 libcompiler_rt.dylib (30) <CE5DBDB4-0124-3E2B-9105-989DF98DD108> /usr/lib/system/libcompiler_rt.dylib 0x93f2b000 - 0x94014ff7 libxml2.2.dylib (22.3) <015A4FA6-5BB9-3F95-AFB8-B9281E22685B> /usr/lib/libxml2.2.dylib 0x94015000 - 0x94016ffd com.apple.TrustEvaluationAgent (2.0 - 23) <E42347C0-2D3C-36A4-9200-757FFA61B388> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x94017000 - 0x94018fff libsystem_sandbox.dylib (220) <4E42390B-25EC-3530-AF01-337E430C16EB> /usr/lib/system/libsystem_sandbox.dylib 0x94019000 - 0x94021fff com.apple.CommerceCore (1.0 - 26) <AF0D1990-8CBF-3AB4-99DF-8B7AE14FB0D5> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore 0x94022000 - 0x9409cff7 com.apple.securityfoundation (6.0 - 55115.4) <A959B2F5-9D9D-3C93-A62A-7399594CF238> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x9409d000 - 0x940c7ff9 com.apple.framework.Apple80211 (8.0.1 - 801.17) <8A8BBBFD-496B-35A6-A26E-ADF8D672D908> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211 0x940c8000 - 0x94137ffb com.apple.Heimdal (3.0 - 2.0) <1ABF438B-30E6-3165-968C-E2EA1A9DF1FD> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x94138000 - 0x94141ffd com.apple.audio.SoundManager (4.0 - 4.0) <ABC5FE40-B222-36EB-9905-5C8C4BFD8C87> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound 0x94142000 - 0x9455ffff FaceCoreLight (2.4.1) <571DE3F8-CA8A-3E71-9AF4-F06FFE721CE6> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight 0x94560000 - 0x9456dfff libGL.dylib (8.6.1) <C7A3917A-C444-33CC-8599-BB9CD8C12BC4> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x9456e000 - 0x94583fff com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <DE68CEB5-4959-3652-83B8-D2B00D3B932D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x94584000 - 0x94592fff libxar.1.dylib (105) <343E4A3B-1D04-34A3-94C2-8C7C9A8F736B> /usr/lib/libxar.1.dylib 0x94593000 - 0x94597ff7 libmacho.dylib (829) <5280A013-4F74-3F74-BE0C-7F612C49F1DC> /usr/lib/system/libmacho.dylib 0x94598000 - 0x9459bfff com.apple.help (1.3.2 - 42) <AD7EB1F0-A068-3A2C-9D59-38E59CEC0D96> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x945aa000 - 0x945b4fff com.apple.speech.recognition.framework (4.1.5 - 4.1.5) <B855E8B4-2EE3-3BFF-8547-98A0F084F9AF> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x945bf000 - 0x945bffff com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) <908B8D40-3FB5-3047-B482-3DF95025ECFC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x945c0000 - 0x945c6fff com.apple.print.framework.Print (8.0 - 258) <12AEAD24-6924-3923-9E4A-C5D21231E639> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x945c7000 - 0x945d2fff libcommonCrypto.dylib (60026) <A6C6EDB8-7E69-3827-81F3-9A74D0935461> /usr/lib/system/libcommonCrypto.dylib 0x945d3000 - 0x9466bfff com.apple.CoreServices.OSServices (557.4 - 557.4) <C724AB29-A596-3E1E-9FF1-A4E509AD843A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x9466c000 - 0x94678ff7 com.apple.NetAuth (4.0 - 4.0) <4983C4B8-9D95-3C4D-897E-07743326487E> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x94679000 - 0x94771ff9 libsqlite3.dylib (138.1) <AD7C5914-35F0-37A3-9238-A29D2E26C755> /usr/lib/libsqlite3.dylib 0x94772000 - 0x94772fff libSystem.B.dylib (169.3) <81C58EAB-0E76-3EAB-BDFD-C5A6FE95536F> /usr/lib/libSystem.B.dylib 0x94776000 - 0x9477dff3 com.apple.NetFS (5.0 - 4.0) <1F7041F2-4E97-368C-8F5D-24153D81BBDB> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x9477e000 - 0x94896ff7 com.apple.coreavchd (5.6.0 - 5600.4.16) <F024C78B-4FAA-38F1-A182-AD0A0A596CBE> /System/Library/PrivateFrameworks/CoreAVCHD.framework/Versions/A/CoreAVCHD 0x94897000 - 0x94897fff com.apple.CoreServices (57 - 57) <956C6C6D-A5DD-314F-9C57-4A61D41F30CE> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x94898000 - 0x94b9dff7 com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) <4571EDDC-704A-3FB1-B9A6-59870AA6165F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x94b9e000 - 0x94c9aff3 com.apple.DiskImagesFramework (10.8 - 344) <98C16F91-9D3E-3FD0-A30B-BD49EE4ED9A4> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages 0x94c9b000 - 0x94cccfff com.apple.DictionaryServices (1.2 - 184.4) <0D5BE86F-F40A-3E39-8569-19FCA5EDF9D3> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x94ccd000 - 0x94ccefff libdnsinfo.dylib (453.18) <41C7B8E2-2A81-31DE-BD8B-F0C29E169D4F> /usr/lib/system/libdnsinfo.dylib 0x94ccf000 - 0x94ce9ffc libsystem_kernel.dylib (2050.18.24) <C17D49D0-7961-3B67-B443-C788C6E5AA76> /usr/lib/system/libsystem_kernel.dylib 0x94cea000 - 0x94d7cffb libvMisc.dylib (380.6) <6DA3A03F-20BE-300D-A664-B50A7B4E4B1A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x94d7d000 - 0x94d7efff libremovefile.dylib (23.1) <98622D14-DAAB-3AD8-A5D9-C322BF572A98> /usr/lib/system/libremovefile.dylib 0x94d7f000 - 0x94d81ffb libRadiance.dylib (845) <3F87840F-217D-3074-A29D-919BAAED2F4A> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x94d82000 - 0x9509fff3 com.apple.Foundation (6.8 - 945.11) <03B242AC-519C-3683-AA52-E73536B3D55F> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x950a0000 - 0x950aafff libCSync.A.dylib (324.6) <D2E8AC70-C6D1-3C40-8A82-E50422EDCFBF> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x950ab000 - 0x9515aff7 com.apple.CoreText (260.0 - 275.16) <873ADCD9-D361-3753-A220-CDD289196AD8> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x9515b000 - 0x95178fff libCRFSuite.dylib (33) <C9D72D0C-871A-39A2-8AFB-682D11AE7D0D> /usr/lib/libCRFSuite.dylib 0x951d0000 - 0x951d1ffd libunc.dylib (25) <58599CBF-E262-3CEA-AFE1-35560E0177DC> /usr/lib/system/libunc.dylib 0x951d2000 - 0x951d2fff com.apple.ApplicationServices (45 - 45) <677C4ACC-9D12-366F-8A87-B898AC806DD9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x951d3000 - 0x95200ffb com.apple.CoreServicesInternal (154.2 - 154.2) <DCCF604B-1DB8-3F09-8122-545E2E7F466D> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0x95203000 - 0x95267fff com.apple.datadetectorscore (4.0 - 269.1) <4D155F09-1A60-325A-BCAC-1B858C2C051B> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x95268000 - 0x95268fff com.apple.quartzframework (1.5 - 1.5) <9018BE5B-4070-320E-8091-6584CC17F798> /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz 0x95269000 - 0x9526bfff libdyld.dylib (210.2.3) <05D6FF2A-F09B-309D-95F7-7AF10259C707> /usr/lib/system/libdyld.dylib 0x9526c000 - 0x95295ff7 libRIP.A.dylib (324.6) <7976E6A2-A489-33F5-A727-7634DDE3B761> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x95298000 - 0x9529bff3 com.apple.AppleSystemInfo (2.0 - 2) <4639D755-8A68-31C9-95C4-7E7F70C233FA> /System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/AppleSystemInfo 0x9529c000 - 0x9529efff libCVMSPluginSupport.dylib (8.6.1) <8A174BD9-992E-351D-8F9A-DF6991723ABE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x9529f000 - 0x95307fe7 libvDSP.dylib (380.6) <55780308-4DCA-3B10-9703-EAFC3E13A3FA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x95308000 - 0x955abffb com.apple.CoreImage (8.2.2 - 1.0.1) <85BFFB09-D765-3F5F-AF65-FB136DDCAEF3> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x955ac000 - 0x95735ff7 com.apple.vImage (6.0 - 6.0) <1D1F67FE-4F75-3689-BEF6-4A46C8039E70> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x95736000 - 0x957befff com.apple.PDFKit (2.7.2 - 2.7.2) <7AE7BAE9-4C21-3BFB-919E-5C6EEBBDFF75> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/PDFKit.framework/Versions/A/PDFKit 0x957f0000 - 0x95847ff3 com.apple.HIServices (1.20 - 417) <561A770B-8523-3D09-A763-11F872779A4C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x95848000 - 0x958fcfff com.apple.coreui (2.0 - 181.1) <C15ABF35-B7F5-34ED-A461-386DAF65D96B> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x958ff000 - 0x9590dfff com.apple.opengl (1.8.6 - 1.8.6) <1AD1AE7B-B57B-35B5-B571-32A34F0DA737> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x9590e000 - 0x9591cff3 libsystem_network.dylib (77.10) <7FBF5A15-97BA-3721-943E-E77F0C40DBE1> /usr/lib/system/libsystem_network.dylib 0x9591d000 - 0x95936fff com.apple.Kerberos (2.0 - 1) <9BDE8F4D-DBC3-34D1-852C-898D3655A611> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x95937000 - 0x95949ff7 libdispatch.dylib (228.23) <86EF7D45-2D97-3465-A449-95038AE5DABA> /usr/lib/system/libdispatch.dylib 0x9594a000 - 0x95a97ffb com.apple.CFNetwork (596.2.3 - 596.2.3) <1221EF86-659B-3136-AB57-0CC6B130CDA2> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x95b50000 - 0x95b53ffd libCoreVMClient.dylib (24.4) <C54E8FD0-61EC-3DC8-8631-54288AC66AC8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x95b8a000 - 0x95be3fff com.apple.AE (645.3 - 645.3) <6745659F-006D-3F25-94D6-DF944E9A01FD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x95be4000 - 0x95be4fff libsystem_blocks.dylib (59) <3A743C5D-CFA5-37D8-80A8-B6795A9DB04F> /usr/lib/system/libsystem_blocks.dylib 0x95be5000 - 0x95d20ff7 libBLAS.dylib (1073.4) <FF74A147-05E1-37C4-BC10-7DEB57FE5326> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x95d21000 - 0x95d96ff7 com.apple.ApplicationServices.ATS (332 - 341.1) <95206704-F9C9-33C4-AF25-FE9890E160B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x95d97000 - 0x95dd7fff com.apple.MediaKit (13 - 659) <37B8C1E3-B67D-3FE6-8A14-7FFD9F31C556> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit 0x95dd8000 - 0x96030ff1 com.apple.JavaScriptCore (8536 - 8536.26.7) <75629E05-65FE-3699-8CDC-80C95015CF42> /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore 0x960ae000 - 0x960b5fff liblaunch.dylib (442.26.2) <310C99F8-0811-314D-9BB9-D0ED6DFA024B> /usr/lib/system/liblaunch.dylib 0x960b6000 - 0x960e9ff3 com.apple.GSS (3.0 - 2.0) <B1D719C1-B000-3BE3-B747-329D608585DD> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x960ea000 - 0x960f1fff libsystem_dnssd.dylib (379.32.1) <6A505284-2382-3F27-B96F-15FFDACF004E> /usr/lib/system/libsystem_dnssd.dylib 0x960f2000 - 0x96100ff7 libz.1.dylib (43) <245F1B61-2276-3BBB-9891-99934116D833> /usr/lib/libz.1.dylib 0x9610d000 - 0x9610dfff com.apple.Cocoa (6.7 - 19) <354094F0-F36B-36F9-BF5F-FD60590FBEB9> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 0x9610e000 - 0x9650afeb com.apple.VideoToolbox (1.0 - 926.62) <B09EEF06-CB3C-3EAA-8B0E-22A1801F3CAE> /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox 0x9650b000 - 0x96537ff7 libsystem_info.dylib (406.17) <AA5611DB-A944-3072-B6BE-ACAB08689547> /usr/lib/system/libsystem_info.dylib 0x96538000 - 0x96591fff com.apple.QuickLookFramework (4.0 - 555.4) <96911441-FDD4-3B68-9E0C-51BA11A97C2E> /System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook 0x96592000 - 0x965e2ff7 com.apple.CoreMediaIO (301.0 - 4147) <F13FA9D4-BD1D-3297-BDD5-5858B231D738> /System/Library/Frameworks/CoreMediaIO.framework/Versions/A/CoreMediaIO 0x965e3000 - 0x9665cff0 com.apple.CorePDF (2.0 - 2) <6B5BF755-F336-359C-9A99-F006F61442CF> /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/CorePDF 0x9665d000 - 0x9667ffff libc++abi.dylib (24.4) <06479DA4-BC23-34B6-BAFC-A885814261D0> /usr/lib/libc++abi.dylib 0x96680000 - 0x966c7ff3 com.apple.CoreMedia (1.0 - 926.62) <69B3835E-C02F-3935-AD39-83F8E81FB780> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia 0x966c8000 - 0x966cafff com.apple.securityhi (4.0 - 55002) <62E3AE75-61CB-341E-B2A0-CFC985A2BF7F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x966cb000 - 0x966ceff7 com.apple.TCC (1.0 - 1) <437D76CD-6437-3B55-BE2C-A53508858256> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x966d3000 - 0x966e3ff2 com.apple.LangAnalysis (1.7.0 - 1.7.0) <875363E7-6D02-3229-A9DD-E5A5568A7D61> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x966e4000 - 0x96802ff7 com.apple.MediaControlSender (1.4.5 - 145.3) <E0931EE7-4ACA-3538-9658-B9B2AC1E6A80> /System/Library/PrivateFrameworks/MediaControlSender.framework/Versions/A/MediaControlSender 0x96803000 - 0x9680dffe com.apple.bsd.ServiceManagement (2.0 - 2.0) <9732BA61-D6F6-3644-82DA-FF0D6FEEFC69> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x9680e000 - 0x96812fff com.apple.CommonPanels (1.2.5 - 94) <6B3E7E53-7708-3DA2-8C50-59C2B4735DE1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x96813000 - 0x96813ffd libOpenScriptingUtil.dylib (148.2) <907E25B1-4F50-3461-B8D5-733C687EB534> /usr/lib/libOpenScriptingUtil.dylib 0x96814000 - 0x96832ff3 com.apple.openscripting (1.3.6 - 148.2) <55738D66-CC15-3F43-9265-00C3322D39C4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x96833000 - 0x96874ff7 libcups.2.dylib (327) <F46F8703-FEAE-3442-87CB-45C8BF98BEE5> /usr/lib/libcups.2.dylib 0x96878000 - 0x968afffa com.apple.LDAPFramework (2.4.28 - 194.5) <8368FAE7-2B89-3A7D-B6EE-7184B522CB66> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP 0x968b0000 - 0x968b6fff libGFXShared.dylib (8.6.1) <E32A7266-FCDD-352C-9C2A-8939265974AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x968b7000 - 0x968f9ffb com.apple.RemoteViewServices (2.0 - 80.5) <60E04F2F-AFD8-3B1F-BF07-8A3A7EABB8E9> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x968fa000 - 0x96906ff8 libbz2.1.0.dylib (29) <7031A4C0-784A-3EAA-93DF-EA1F26CC9264> /usr/lib/libbz2.1.0.dylib 0x96907000 - 0x9693dffb com.apple.DebugSymbols (98 - 98) <9A9ADA0A-E487-3C8F-9998-286EE04C235A> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x9693e000 - 0x9699bfff com.apple.audio.CoreAudio (4.1.0 - 4.1.0) <9549B81F-4425-34EE-802B-F462068DC0C5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x9699c000 - 0x96a00ff3 libstdc++.6.dylib (56) <F8FA490A-8F3C-3645-ABF5-78926CE9C62C> /usr/lib/libstdc++.6.dylib 0x96af7000 - 0x96b1cff7 com.apple.quartzfilters (1.8.0 - 1.7.0) <F6A88D89-AB4A-3217-9D65-C2C259B5F09B> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzFilters.framework/Versions/A/QuartzFilters 0x96b1d000 - 0x96b1dfff com.apple.Accelerate (1.8 - Accelerate 1.8) <4EC0548E-3A3F-310D-A366-47B51D5B6398> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x96b1e000 - 0x96b1ffff libDiagnosticMessagesClient.dylib (8) <39B3D25A-148A-3936-B800-0D393A00E64F> /usr/lib/libDiagnosticMessagesClient.dylib 0x96b20000 - 0x96b79ff7 com.apple.ImageCaptureCore (5.0.1 - 5.0.1) <541529F7-063E-370B-9EB2-DF5BE39073E6> /System/Library/Frameworks/ImageCaptureCore.framework/Versions/A/ImageCaptureCore 0x96b7a000 - 0x96b9fff7 com.apple.CoreVideo (1.8 - 99.3) <5B872AC0-E82D-3475-A3F9-FD95F380560D> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x96ba0000 - 0x96ba4fff com.apple.IOSurface (86.0.3 - 86.0.3) <E3A4DB0A-1C1A-31E3-A550-5C0E1C874509> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x96ba5000 - 0x96c3cff7 com.apple.ink.framework (10.8.2 - 150) <D90FF7BC-6B90-39F1-AC52-670269947C58> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x96c3d000 - 0x96c62ffb com.apple.framework.familycontrols (4.1 - 410) <5A8504E7-D95D-3101-8E20-38EADE8DEAE1> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x96c63000 - 0x96c64fff liblangid.dylib (116) <E13CC8C5-5034-320A-A210-41A2BDE4F846> /usr/lib/liblangid.dylib 0x96f95000 - 0x96fe1fff libcorecrypto.dylib (106.2) <20EBADBA-D6D6-36F0-AE80-168E9AF13DB6> /usr/lib/system/libcorecrypto.dylib 0x96fe2000 - 0x9766efeb com.apple.CoreAUC (6.16.00 - 6.16.00) <654A0AB8-F24F-3489-8F70-F0A22414FE08> /System/Library/PrivateFrameworks/CoreAUC.framework/Versions/A/CoreAUC 0x9769e000 - 0x977ab057 libobjc.A.dylib (532.2) <FA455371-7395-3D58-A89B-D1520612D1BC> /usr/lib/libobjc.A.dylib 0x97815000 - 0x97821ffe libkxld.dylib (2050.18.24) <48A75AF6-9D5A-3552-948E-30A1682D3664> /usr/lib/system/libkxld.dylib 0x97822000 - 0x9797fffb com.apple.QTKit (7.7.1 - 2599.13) <2DC9E2BB-9895-3D02-A318-88431052E70B> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit 0x97980000 - 0x97993ff9 com.apple.MultitouchSupport.framework (235.28 - 235.28) <5C8CFA21-D4FC-32E8-B199-0F7155E6ED9A> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x97994000 - 0x979b0ff7 libPng.dylib (845) <14C43094-C670-3575-BF9B-3A967E05EAC0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x979b1000 - 0x97a17fff com.apple.print.framework.PrintCore (8.1 - 387.1) <F8CF762B-B707-3021-958F-BB8D33DB3576> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x97a1f000 - 0x97c36fff com.apple.CoreData (106.1 - 407.7) <17FD06D6-AD7C-345A-8FA4-1F0FBFF4DAE1> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x97c37000 - 0x97d0dfff com.apple.DiscRecording (7.0 - 7000.2.4) <C14E99B9-DEFA-3812-89E5-464653B729F4> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording 0x97d3e000 - 0x97d98fff com.apple.Symbolication (1.3 - 93) <684ECF0D-D416-3DF8-8B5B-3902953853A8> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x97d99000 - 0x98015ff7 com.apple.QuickTime (7.7.1 - 2599.13) <FE609160-E1EF-341D-9B6A-205D3E03A4D2> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime 0x98016000 - 0x9802dff4 com.apple.CoreMediaAuthoring (2.1 - 914) <37C0A2C7-73B3-39BC-8DE1-4A6B75F115FC> /System/Library/PrivateFrameworks/CoreMediaAuthoring.framework/Versions/A/CoreMediaAuthoring 0x9802e000 - 0x98043fff com.apple.ImageCapture (8.0 - 8.0) <B8BD421F-D5A9-3FB4-8E89-AD5CFC0D4030> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x98044000 - 0x98085ff7 com.apple.framework.CoreWiFi (1.0 - 100.10) <944B3FAE-F901-3276-A676-9D52295DA817> /System/Library/Frameworks/CoreWiFi.framework/Versions/A/CoreWiFi 0x98086000 - 0x980b9ff5 libssl.0.9.8.dylib (47) <3224FBB3-3074-3022-AD9A-187703680C03> /usr/lib/libssl.0.9.8.dylib 0x980bf000 - 0x98127ff7 com.apple.framework.IOKit (2.0 - 755.18.10) <9A80E97E-544F-3A45-916D-6DB7ED217E33> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x98128000 - 0x98128fff com.apple.vecLib (3.8 - vecLib 3.8) <83160DD1-5614-3E34-80EB-97041016EF1F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x9814d000 - 0x98150ffc libpam.2.dylib (20) <FCF74195-A99E-3B07-8E49-688D4A6F1E18> /usr/lib/libpam.2.dylib 0x9815d000 - 0x9815dfff libkeymgr.dylib (25) <D5E93F7F-9315-3AD6-92C7-941F7B54C490> /usr/lib/system/libkeymgr.dylib 0x98e97000 - 0x98eeeff7 com.apple.ScalableUserInterface (1.0 - 1) <2B5E454B-BC49-3E85-B54D-1950397C448C> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface 0x98eef000 - 0x98f2eff7 com.apple.bom (12.0 - 192) <0637E52C-D151-37B3-904F-8656B2FD44DD> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x98f2f000 - 0x9904bff7 com.apple.desktopservices (1.7.2 - 1.7.2) <8E74D101-8398-34F1-A463-B4950680A597> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x9904c000 - 0x991c4ff5 com.apple.QuartzCore (1.8 - 304.0) <0B0EC55A-9084-3E28-9A84-1813CE3FAA9B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x991c5000 - 0x99381ffd libicucore.A.dylib (491.11.1) <B19E450A-BAF1-3967-9C95-7F77DC0B4639> /usr/lib/libicucore.A.dylib 0x99382000 - 0x993e4fff libc++.1.dylib (65.1) <C0CFF9FF-5D52-3EAE-B921-6AE1DA00A135> /usr/lib/libc++.1.dylib 0x993e5000 - 0x99402ff7 libresolv.9.dylib (51) <B9742A2A-DF15-3F6E-8FCE-778A58214B3A> /usr/lib/libresolv.9.dylib 0x99406000 - 0x9940dffe com.apple.agl (3.2.1 - AGL-3.2.1) <8E0411D3-19F7-30E1-92A2-337F7F0EBCDA> /System/Library/Frameworks/AGL.framework/Versions/A/AGL 0x9940e000 - 0x997f1ff3 com.apple.HIToolbox (2.0 - 625) <5A312E41-9940-363E-B891-90C4672E6850> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x997f2000 - 0x997feffa com.apple.CrashReporterSupport (10.8.2 - 415) <BAE9900A-51E7-3AD4-A7FB-7E6CCFFB2F21> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x99a99000 - 0x99a99ffd com.apple.audio.units.AudioUnit (1.8 - 1.8) <4C13DEA2-1EB0-3D06-901A-DB93184C06F0> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x99bdc000 - 0x99bdcfff com.apple.Carbon (154 - 155) <604ADD9D-5835-3294-842E-3A4AEBCCB548> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x99be8000 - 0x99c2afff libcurl.4.dylib (69.2) <8CC566A0-0B25-37E8-A6EC-30074C3CDB8C> /usr/lib/libcurl.4.dylib 0x99c2b000 - 0x99cfffff com.apple.backup.framework (1.4.1 - 1.4.1) <55F2A679-9B21-3F43-A580-4C2ECF6A5FC5> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x99d00000 - 0x99d04ffc libGIF.dylib (845) <714E9F0D-D7A3-3F58-B46E-FCBE0F144B23> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x99d05000 - 0x99d12ff7 com.apple.AppleFSCompression (49 - 1.0) <166AA1F8-E50A-3533-A3B5-8737C5118CC3> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x99d13000 - 0x99d37fff libJPEG.dylib (845) <547FA9A5-0BBB-3E39-BACA-F3E2DAE57DB0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x9a4aa000 - 0x9a4c1fff com.apple.GenerationalStorage (1.1 - 132.2) <93694E0D-35D3-3633-976E-F354CBD92F54> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x9a4c2000 - 0x9a4cafff com.apple.DiskArbitration (2.5.1 - 2.5.1) <25A7232F-9B6A-3746-A3A8-12479D086B1E> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x9a501000 - 0x9a546ff7 com.apple.NavigationServices (3.7 - 200) <F6531764-6E43-3AF3-ACDD-8A5551EF016A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x9a547000 - 0x9a582fe7 libGLImage.dylib (8.6.1) <A3442557-18D5-332E-8859-423D5A20EBBE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x9a58a000 - 0x9a695ff7 libJP2.dylib (845) <D409C913-6FA4-3D60-BFE0-B9FC6A02FEE0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x9a696000 - 0x9a69dffb libunwind.dylib (35.1) <E1E8D8B3-3C78-3AB1-B398-C180DC6DCF05> /usr/lib/system/libunwind.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 81272 thread_create: 3 thread_set_state: 4130 VM Region Summary: ReadOnly portion of Libraries: Total=154.0M resident=68.0M(44%) swapped_out_or_unallocated=86.0M(56%) Writable regions: Total=662.3M written=172K(0%) resident=76.0M(11%) swapped_out=5492K(1%) unallocated=586.3M(89%) REGION TYPE VIRTUAL =========== ======= ATS (font support) 31.9M ATS (font support) (reserved) 4K reserved VM address space (unallocated) CG image 28K CoreServices 4612K MALLOC 90.9M MALLOC guard page 48K Memory tag=240 4K Memory tag=242 12K Memory tag=243 4K Memory tag=35 4552K OpenCL 20K Stack 67.0M VM_ALLOCATE 528.1M __DATA 7356K __DATA/__OBJC 188K __IMAGE 528K __LINKEDIT 31.8M __OBJC 2384K __OBJC/__DATA 116K __PAGEZERO 4K __TEXT 122.2M __UNICODE 544K mapped file 87.3M shared memory 12K =========== ======= TOTAL 979.3M TOTAL, minus reserved VM space 979.3M On 22.11.2012, at 17:22, Max Leske <maxleske@gmail.com> wrote:
On 22.11.2012, at 17:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 16:34, David T. Lewis <lewis@mail.msen.com> wrote:
On Thu, Nov 22, 2012 at 04:04:00PM +0100, Max Leske wrote:
On 22.11.2012, at 12:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work:
pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ]
The file 'foo.log' is never created.
The UnixOSProcessPlugin has pretty much the same code:
((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ]
BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created).
Assuming that you are trying to do a fork followed by exec,
That's the plan, although I'll have to do some stuff with the pipes before exec'ing.
you will want to do the exec immediately after the fork. This may introduce some complications when you do it as two FFI calls, because your child process is still running Smalltalk on the VM, and it needs to keep running long enough to the second FFI call. Opening a new file stream on 'foo.log' implies a *lot* of processing in the child VM, so I am not surprised that this does not work.
You might try just making a little "hello world" C program, and see if you can exec that program after doing the fork. That would be a lot less processing for your child VM, so it may have a better chance of working. But you still may have a few issues to sort out in keeping the child VM running long enough to get the the exec FFI call.
Ok. Not quite sure how that all works but I tried to come up with a program that is as short as possible:
run | pid args | args := (LimboCommand new command: '/bin/echo'; arguments: { 'foo' }) primitiveArguments. pid := self primitiveRun. pid isZero ifTrue: [ self primitiveExecv: args first arguments: args ] ifFalse: [ "parent code" ].
Still not working. fork() does create the child process but it won't exec (because it never reaches that point in execution somehow) and I can't kill the child process on the command line (have to close the image; the childs are not zombies)
aye... and with a bit of assembler black magic you can actually generate a code to call those two functions in same primitive, so you don't leave to interpreter at all.
Cool :) Will be my last resort though.
Regarding the "hanging" image: yes the child process is created but as the man page for fork() states that the parent will be suspended until the child is exec'ed. Therefore, having the image "hang" is expected because I can't exec the child.
Thanks for the help guys.
Max
bit still it would be nice if it could work using two separate FFI calls.
Dave
Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: 1. possible use of a sig handler 2. special secure mode handling (what's that?) 3. turn off the interval timer
Any ideas?
Cheers, Max
On 21.11.2012, at 08:50, Max Leske <maxleske@gmail.com> wrote:
On 20.11.2012, at 21:56, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote:
Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try.
And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess.
In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case.
The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started).
Thanks Dave, that's good to know.
Cheers, Max
Dave
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 23 November 2012 16:19, Max Leske <maxleske@gmail.com> wrote:
I did some more digging and I found that I was wrong before: every child process I create through NB is killed immediately and becomes a zombie (that's why it ignored the kill). Once I had that information I implemented the waitpid() call and can now cleanup my zombie children. This would also explain (at least to my mind) why the child code (pid = 0 ifTrue: [ ⦠]) is never executed.
Now, my question is, who terminates my child processes?
The processes are terminated with SIGABRT; all of the above also applies to vfork(). I found that there's a crash report being generated for that aborted process so I'm attaching it here, maybe you'll see something I missed.
Max
i would start from here:
Application Specific Information: *** multi-threaded process forked *** abort() called
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-usin... damn... why unix (POSIX) kernels don't have spawn_exec() which spawns a new process without need to do a fork() in current? -- Best regards, Igor Stasenko.
so here's the answer: - no you cannot use FFI for fork/exec.. because there's too much involved. Ideally VM should have support for it, because i think even OSProcess lacking important bits, like: - closing all file descriptors (and in unix fd is not just files, but for sockets as well) - cleaning/preparing environment before doing exec - god knows what else. now if we take into account that different parts (sockets/files) in VM responsible for them, and need coordination to do a safe cleanup after fork.. i don't think it will be possible to do that using FFI. just too much management. -- Best regards, Igor Stasenko.
Ok, thanks Igor. So it seems the only remaining option (apart from providing a C library) it to use Assembly. Assembly is not my territory at all but here's how I think it could work: ⦠emitCall: [:gen | | fork dup2 execv | fork := NativeBoost forCurrentPlatform getGlobalSymbolPointer: 'fork'. dup2 := NativeBoost forCurrentPlatform getGlobalSymbolPointer: 'dup2'. execv := NativeBoost forCurrentPlatform getGlobalSymbolPointer gen asm mov: fork asUImm32 to: gen asm EAX. gen asm call: gen asm EAX. "somehow get the fork return value and test for 0. only execute the following lines if pid = 0" gen asm mov: dup2 asUImm32 to: gen asm EAX. gen asm call: gen asm EAX. gen asm mov: execv asUImm32 to: gen asm EAX. gen call: gen asm EAX. ] As you can see, I have absolutely no clue what I'm doing :) (just a good copycat). I figure that everything from fork() to exec() needs to be in the same Assembly sequence to ensure that the child process doesn't try to execute VM code (multiple #emitCall:'s probably wouldn't work). I think that if you could help me fill in the code for where I simply used a comment, I could come up with the rest (writing function specs etc.). I'l try at least. Cheers, Max On 23.11.2012, at 17:00, Igor Stasenko <siguctua@gmail.com> wrote:
so here's the answer: - no you cannot use FFI for fork/exec.. because there's too much involved.
Ideally VM should have support for it, because i think even OSProcess lacking important bits, like: - closing all file descriptors (and in unix fd is not just files, but for sockets as well) - cleaning/preparing environment before doing exec - god knows what else.
now if we take into account that different parts (sockets/files) in VM responsible for them, and need coordination to do a safe cleanup after fork.. i don't think it will be possible to do that using FFI. just too much management.
-- Best regards, Igor Stasenko.
On 23 November 2012 18:00, Max Leske <maxleske@gmail.com> wrote:
Ok, thanks Igor.
So it seems the only remaining option (apart from providing a C library) it to use Assembly. Assembly is not my territory at all but here's how I think it could work:
⦠emitCall: [:gen | | fork dup2 execv | fork := NativeBoost forCurrentPlatform getGlobalSymbolPointer: 'fork'. dup2 := NativeBoost forCurrentPlatform getGlobalSymbolPointer: 'dup2'. execv := NativeBoost forCurrentPlatform getGlobalSymbolPointer gen asm mov: fork asUImm32 to: gen asm EAX. gen asm call: gen asm EAX. "somehow get the fork return value and test for 0. only execute the following lines if pid = 0" gen asm mov: dup2 asUImm32 to: gen asm EAX. gen asm call: gen asm EAX. gen asm mov: execv asUImm32 to: gen asm EAX. gen call: gen asm EAX. ]
As you can see, I have absolutely no clue what I'm doing :) (just a good copycat). I figure that everything from fork() to exec() needs to be in the same Assembly sequence to ensure that the child process doesn't try to execute VM code (multiple #emitCall:'s probably wouldn't work).
I think that if you could help me fill in the code for where I simply used a comment, I could come up with the rest (writing function specs etc.). I'l try at least.
yes i can help. where i can get the code? btw, your code is actually very close to how it should be done.
Cheers, Max
-- Best regards, Igor Stasenko.
On 23.11.2012, at 18:12, Igor Stasenko <siguctua@gmail.com> wrote:
On 23 November 2012 18:00, Max Leske <maxleske@gmail.com> wrote:
Ok, thanks Igor.
So it seems the only remaining option (apart from providing a C library) it to use Assembly. Assembly is not my territory at all but here's how I think it could work:
⦠emitCall: [:gen | | fork dup2 execv | fork := NativeBoost forCurrentPlatform getGlobalSymbolPointer: 'fork'. dup2 := NativeBoost forCurrentPlatform getGlobalSymbolPointer: 'dup2'. execv := NativeBoost forCurrentPlatform getGlobalSymbolPointer gen asm mov: fork asUImm32 to: gen asm EAX. gen asm call: gen asm EAX. "somehow get the fork return value and test for 0. only execute the following lines if pid = 0" gen asm mov: dup2 asUImm32 to: gen asm EAX. gen asm call: gen asm EAX. gen asm mov: execv asUImm32 to: gen asm EAX. gen call: gen asm EAX. ]
As you can see, I have absolutely no clue what I'm doing :) (just a good copycat). I figure that everything from fork() to exec() needs to be in the same Assembly sequence to ensure that the child process doesn't try to execute VM code (multiple #emitCall:'s probably wouldn't work).
I think that if you could help me fill in the code for where I simply used a comment, I could come up with the rest (writing function specs etc.). I'l try at least.
yes i can help. where i can get the code? btw, your code is actually very close to how it should be done.
Awesome! The Smalltalk code is here: http://ss3.gemstone.com/ss/Limbo.html. The C code is on Github: https://github.com/theseion/liblimbo. Functions: fork() -> LimboFork dup2() -> LimboDup2 close() -> LimboPipe execv() -> LimboFork Please ignore the hideousness of the code, I'm just trying to get it to work before doing it nice and clean.
Cheers, Max
-- Best regards, Igor Stasenko.
On 22 November 2012 16:04, Max Leske <maxleske@gmail.com> wrote:
On 22.11.2012, at 12:28, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2012 11:19, Max Leske <maxleske@gmail.com> wrote:
I have run into a small problem with fork():
pid := self primitiveRun. pid isZero ifTrue: [ "child code with exec" ] ifFalse: [ "parent code" ]
primitiveRun <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( int fork() )
Only the parent code is ever executed, #pid is never 0.
are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value.
Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work:
pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ]
The file 'foo.log' is never created.
The UnixOSProcessPlugin has pretty much the same code:
((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ]
BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created).
what you mean image hangs? do you see if child process created? -- Best regards, Igor Stasenko.
For those interested, the code for the library is now on github: https://github.com/theseion/liblimbo On 19.11.2012, at 21:26, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 November 2012 17:17, Max Leske <maxleske@gmail.com> wrote:
Hi everyone.
I want to announce the first (and *very* basic) version of Limbo. Limbo is a simple wrapper around NativeBoost that lets you run commands on the shell (via sh) or directly (no shell expansion).
why you need to wrap around NativeBoost? perhaps a more correct phrasing would be 'using nativeboost'?
To use Limbo you will need the NBCog VM and install NativeBoost into your image (with "NBInstaller install"). You will also need to build the shared library from the archive attached to this e-mail and put it into the "Plugins" directory of the VM (instructions inside the archive). I also attached the xcode project.
The Limbo repo:
MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/Limbo' user: '' password: ''
I am *not* an experienced C coder so there might be some horrible stuff in the box. If you have any suggestions / requests / bug reports or would like to contribute, let me know.
Disclaimer: NativeBoost uses direct memory access. I have written Limbo to the best of my memory layout knowledge (I'm quite a n00b there) but cannot and will not guarantee that you might not experience memory leaks or VM crashes (or any type of crash for that matter). This is just a warning, I haven't had any troubles at all with Limbo so far.
Hmm.. what is the C part for? The whole idea of using NativeBoost is to avoid writing a single line of C code. Because if you cannot avoid that, writing a VM plugin turns to be more preferable. But i didn't saw your code yet, so just commenting what on surface :)
Cheers, Max
-- Best regards, Igor Stasenko.
Okay, after i saw C code in limbo.c i can clearly tell, that read_buffers() function can be implemented purely on smalltalk using nativeboost. as for run_command() function, you should try to also implement it as a series of system calls using nativeboost ffi. it is possible. The most issues would be is to account for scheduler to make sure that no-one can interrupt the process between critical parts of code (like VM scheduler). You should really consider avoiding having C code at all.. because at the end it doesn't makes things any simpler comparing to having extra VM plugin (and knowing how to deal with it - compile/copy/distribute with VM) for users. But anyways, good to see there's brave people who don't fear to swim in those waters :) -- Best regards, Igor Stasenko.
On 19.11.2012, at 21:37, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, after i saw C code in limbo.c i can clearly tell, that read_buffers() function can be implemented purely on smalltalk using nativeboost.
as for run_command() function, you should try to also implement it as a series of system calls using nativeboost ffi. it is possible.
The most issues would be is to account for scheduler to make sure that no-one can interrupt the process between critical parts of code (like VM scheduler).
:-/ sounds trickyâ¦
You should really consider avoiding having C code at all.. because at the end it doesn't makes things any simpler comparing to having extra VM plugin (and knowing how to deal with it - compile/copy/distribute with VM) for users.
Good to know! Now that I have a working version in C I think that it should be a lot easier to write the equivalent NativeBoost code since I know what actually to code :) It's also pretty easy to just replace the call to the library with the NB code in Limbo, so any code using the library will keep on working. Anybody willing to write this in NativeBoost is more than welcome, I'll have to stop working on it for the moment.
But anyways, good to see there's brave people who don't fear to swim in those waters :)
Thanks :)
-- Best regards, Igor Stasenko.
On 19 November 2012 17:45, Max Leske <maxleske@gmail.com> wrote:
On 19.11.2012, at 21:37, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, after i saw C code in limbo.c i can clearly tell, that read_buffers() function can be implemented purely on smalltalk using nativeboost.
as for run_command() function, you should try to also implement it as a series of system calls using nativeboost ffi. it is possible.
The most issues would be is to account for scheduler to make sure that no-one can interrupt the process between critical parts of code (like VM scheduler).
:-/ sounds trickyâ¦
nope. this part is actually easy: [ something which should not interrupt] forkAt: Processor highestPriority.
You should really consider avoiding having C code at all.. because at the end it doesn't makes things any simpler comparing to having extra VM plugin (and knowing how to deal with it - compile/copy/distribute with VM) for users.
Good to know! Now that I have a working version in C I think that it should be a lot easier to write the equivalent NativeBoost code since I know what actually to code :)
Indeed. :)
It's also pretty easy to just replace the call to the library with the NB code in Limbo, so any code using the library will keep on working.
Anybody willing to write this in NativeBoost is more than welcome, I'll have to stop working on it for the moment.
But anyways, good to see there's brave people who don't fear to swim in those waters :)
Thanks :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 19.11.2012, at 21:48, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 November 2012 17:45, Max Leske <maxleske@gmail.com> wrote:
On 19.11.2012, at 21:37, Igor Stasenko <siguctua@gmail.com> wrote:
Okay, after i saw C code in limbo.c i can clearly tell, that read_buffers() function can be implemented purely on smalltalk using nativeboost.
as for run_command() function, you should try to also implement it as a series of system calls using nativeboost ffi. it is possible.
The most issues would be is to account for scheduler to make sure that no-one can interrupt the process between critical parts of code (like VM scheduler).
:-/ sounds trickyâ¦
nope. this part is actually easy:
[ something which should not interrupt] forkAt: Processor highestPriority.
Sweet. I'll give it a try.
You should really consider avoiding having C code at all.. because at the end it doesn't makes things any simpler comparing to having extra VM plugin (and knowing how to deal with it - compile/copy/distribute with VM) for users.
Good to know! Now that I have a working version in C I think that it should be a lot easier to write the equivalent NativeBoost code since I know what actually to code :)
Indeed. :)
It's also pretty easy to just replace the call to the library with the NB code in Limbo, so any code using the library will keep on working.
Anybody willing to write this in NativeBoost is more than welcome, I'll have to stop working on it for the moment.
But anyways, good to see there's brave people who don't fear to swim in those waters :)
Thanks :)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (3)
-
David T. Lewis -
Igor Stasenko -
Max Leske