Re: Cross plaform issues
My bad, I've not looked enouth on the poll api. On 5/18/05, Mladen Turk <[EMAIL PROTECTED]> wrote: > > Rodrigo Kumpera wrote: > > A quick look at APR reveal that it doesn´t provide all OS abstraction > that a > > JVM needs. > > I tend to disagree with you. The only thing the APR doesn't offer is > GUI abstraction. > > > There are no functions to mark pages as executable, > > Like Garrett said, those functionality was not needed. > Not sure if it can be added in a portable fashion to APR or > if this should be kept as separate lib. > > > scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for > > small diferences on syscalls or libC implementation. > > Take a look at: > jakarta-tomcat-connectors/jni > It uses APR in a way the Sun does for it's low level I/O. > > On windows, APR currently uses select, but we are discussing to use the > IOCP for quite some time. On other platforms, either poll, epoll or > kqueue are used. > > Regards, > Mladen. >
Re: Cross plaform issues
Rodrigo Kumpera wrote: A quick look at APR reveal that it doesn´t provide all OS abstraction that a JVM needs. I tend to disagree with you. The only thing the APR doesn't offer is GUI abstraction. There are no functions to mark pages as executable, Like Garrett said, those functionality was not needed. Not sure if it can be added in a portable fashion to APR or if this should be kept as separate lib. scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for small diferences on syscalls or libC implementation. Take a look at: jakarta-tomcat-connectors/jni It uses APR in a way the Sun does for it's low level I/O. On windows, APR currently uses select, but we are discussing to use the IOCP for quite some time. On other platforms, either poll, epoll or kqueue are used. Regards, Mladen.
Re: Cross plaform issues
Garrett Rooney wrote: access to scalable IO facilities (IOCP, epoll, kqueue, etc...) See the apr_pool API, which uses epoll, kqueue, etc on the backend if available. Now that my message finally makes it through the ASF mail system, I notice that typo... That should be "apr_poll", not "apr_pool" ;-) -garrett
Re: Cross plaform issues
On Tue, May 17, 2005 at 05:56:36PM -0300, Rodrigo Kumpera wrote: > A quick look at APR reveal that it doesn?t provide all OS abstraction that a > JVM needs. There are no functions to mark pages as executable, access to > scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for > small diferences on syscalls or libC implementation. > I think Harmony should use autotools and some m4 magic to help with that. Like the linux kernel source tree and the arch/ subtree ?
Re: Cross plaform issues
Rodrigo Kumpera wrote: A quick look at APR reveal that it doesn´t provide all OS abstraction that a JVM needs. There are no functions to mark pages as executable, This is probably not there, but could be added to APR if people were interested and willing to write the code. access to scalable IO facilities (IOCP, epoll, kqueue, etc...) See the apr_pool API, which uses epoll, kqueue, etc on the backend if available. or workarounds for small diferences on syscalls or libC implementation. Uhh, that's what most of APR is... Not that I'm saying APR should definately be used, but in the interests of accuracy... -garrett
Cross plaform issues
A quick look at APR reveal that it doesn´t provide all OS abstraction that a JVM needs. There are no functions to mark pages as executable, access to scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for small diferences on syscalls or libC implementation. I think Harmony should use autotools and some m4 magic to help with that. Rodrigo
