From: Nikodemus S. <nik...@ra...> - 2008-10-29 11:51:13
Attachments:
sb-cpu-affinity-0.2.tar.gz
|
Attached is an early incarnation of lisp API to the Linux CPU affinity masks. I would rather stick this in SBCL than maintain it as a separate package. Any opinions as to where in SBCL I should stick this? A Linux-only contrib? In SB-THREAD with a null implementation on other OSes? Make a new SB-LINUX contrib for things like this? Current usage: (asdf:oos 'asdf:load-op :sb-cpu-affinity) (use-package :sb-cpu-affinity) (with-cpu-affinity-mask (mask) (print mask)) (with-cpu-affinity-mask (mask :save t) ;; Remove all (clear-cpu-affinity-mask mask) ;; Set CPU 0. (setf (cpu-affinity-p 0 mask) t)) (with-cpu-affinity-mask (mask) (print mask)) (with-cpu-affinity-mask (mask :save t) ;; Only odd CPUs in mask. (dotimes (cpu (cpu-count)) (setf (cpu-affinity-p cpu mask) (oddp cpu)))) (with-cpu-affinity-mask (mask) (print mask)) Cheers, -- Nikodemus |
From: Zach B. <xa...@xa...> - 2008-10-29 12:44:13
|
On Wed, Oct 29, 2008 at 01:43:58PM +0200, Nikodemus Siivola wrote: > Attached is an early incarnation of lisp API to the Linux CPU affinity masks. > > I would rather stick this in SBCL than maintain it as a separate > package. Any opinions as to where in SBCL I should stick this? A > Linux-only contrib? In SB-THREAD with a null implementation on other > OSes? Make a new SB-LINUX contrib for things like this? I can't comment on this specific feature, but I'd love to see something like an SB-LINUX as a repository for things like epoll, inotify, Linux-specific sockopts, etc. And something for non-Linux kqueues, and whatever other goodies non-Linuxes have... Zach |
From: Nikodemus S. <nik...@ra...> - 2008-10-30 16:00:57
|
On Wed, Oct 29, 2008 at 2:44 PM, Zach Beane <xa...@xa...> wrote: > I can't comment on this specific feature, but I'd love to see > something like an SB-LINUX as a repository for things like epoll, > inotify, Linux-specific sockopts, etc. And something for non-Linux > kqueues, and whatever other goodies non-Linuxes have... I agree for many things SB-<PLATFORM> makes a fair deal of sense. I think in this case I will keep SB-CPU-AFFINITY as a separate package for a while, though -- till there are at least a couple of other things in addition that could be stuffed into SB-LINUX. (So that they could have interfaces with similar thinness/niceness tradeoffs.) Cheers, -- Nikodemus |
From: Chun T. (binghe) <bin...@gm...> - 2008-10-30 21:47:26
|
> On Wed, Oct 29, 2008 at 01:43:58PM +0200, Nikodemus Siivola wrote: >> Attached is an early incarnation of lisp API to the Linux CPU >> affinity masks. >> >> I would rather stick this in SBCL than maintain it as a separate >> package. Any opinions as to where in SBCL I should stick this? A >> Linux-only contrib? In SB-THREAD with a null implementation on other >> OSes? Make a new SB-LINUX contrib for things like this? > > I can't comment on this specific feature, but I'd love to see > something like an SB-LINUX as a repository for things like epoll, > inotify, Linux-specific sockopts, etc. And something for non-Linux > kqueues, and whatever other goodies non-Linuxes have... Talking about epoll(), kqueue(), and sockopt-related stuff. I must say IOLib's net.sockets and io.multiplex packages have defined very good APIs, which may be learnt by USOCKET later (which built on implementation-specific API but CFFI). --binghe |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-10-30 22:06:08
|
On Thu, Oct 30, 2008 at 5:17 PM, Chun Tian (binghe) <bin...@gm...> wrote: > > >> On Wed, Oct 29, 2008 at 01:43:58PM +0200, Nikodemus Siivola wrote: >>> Attached is an early incarnation of lisp API to the Linux CPU >>> affinity masks. >>> >>> I would rather stick this in SBCL than maintain it as a separate >>> package. Any opinions as to where in SBCL I should stick this? A >>> Linux-only contrib? In SB-THREAD with a null implementation on other >>> OSes? Make a new SB-LINUX contrib for things like this? >> >> I can't comment on this specific feature, but I'd love to see >> something like an SB-LINUX as a repository for things like epoll, >> inotify, Linux-specific sockopts, etc. And something for non-Linux >> kqueues, and whatever other goodies non-Linuxes have... > > Talking about epoll(), kqueue(), and sockopt-related stuff. I must say > IOLib's net.sockets and io.multiplex packages have defined very good > APIs, which may be learnt by USOCKET later (which built on > implementation-specific API but CFFI). Hi Chun, One of the problems USOCKET is suffering from is that not all implementation defined APIs actually export an api to set socket options... (Too bad, but true, sadly). Bye, Erik. |