Hi,
Sorry my question is very SBCL oriented.
In more of being a good Common Lisp implementation (and, as I
understand it, speeding software prototyping and preventing to invent
the wheel again and again in C), is SBCL a good tool to deal with the
underlying unix ? That is in terms of scripting processes and flows and
in terms of doing system programming, like get a process that (for its
unix part) :
- open a device in /dev to regularly read a few kB of data,
- open a few pipes to exchange data with some processes,
- listen a socket to receive commands from another machine,
- launch and respond to a few seconds timer to write structures on
disk,
- finally multiplex all this i/o with a select syscall.
Is it currently possible, what are the limitations ?
If there are too many, would it be difficult (absurd, just a matter of
will and time...) to dive into SBCL/Linux and achieve this goal ?
Thanks.
"Patrice Lespagnol" <·················@obs-nancay.fr> writes:
> Hi,
> Sorry my question is very SBCL oriented.
> In more of being a good Common Lisp implementation (and, as I
> understand it, speeding software prototyping and preventing to invent
> the wheel again and again in C), is SBCL a good tool to deal with the
> underlying unix ?
SBCL has FFI, so you can do, unix wise, all you can do in C, in SBCL.
(I'd advise to use CFFI instead of the ALIEN (FFI) package of SBCL,
since it's a portability layer that would allow you to change of Lisp
implementation if the need appeared.)
> That is in terms of scripting processes
For scripting, I prefer clisp (smaller, and faster to load), but both
clisp and sbcl can be run as #! "interpreters".
> and flows and
> in terms of doing system programming, like get a process that (for its
> unix part) :
> - open a device in /dev to regularly read a few kB of data,
(with-open-file #| remember on unix devices are files! |#
(input "/dev/urandom" :element-type '(unsigned-byte 8))
(let ((kb (make-array 1024 :element-type '(unsigned-byte 8))))
(dotimes (a-few (random 4))
(read-sequence kb))))
> - open a few pipes to exchange data with some processes,
> - listen a socket to receive commands from another machine,
> - launch and respond to a few seconds timer to write structures on
> disk,
> - finally multiplex all this i/o with a select syscall.
All the above is possible in SBCL (and in the other implementations),
but is implementation specific. The implementations provide different
lisp API to do it, or you can use FFI to do it like in C.
> Is it currently possible,
Yes.
> what are the limitations ?
No different than in C.
> If there are too many, would it be difficult (absurd, just a matter of
> will and time...) to dive into SBCL/Linux and achieve this goal ?
Not at all. Go ahead.
> Thanks.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
Pascal Bourguignon wrote:
> "Patrice Lespagnol" <·················@obs-nancay.fr> writes:
>
> > Hi,
> > Sorry my question is very SBCL oriented.
> > In more of being a good Common Lisp implementation (and, as I
> > understand it, speeding software prototyping and preventing to invent
> > the wheel again and again in C), is SBCL a good tool to deal with the
> > underlying unix ?
>
> SBCL has FFI, so you can do, unix wise, all you can do in C, in SBCL.
>
> (I'd advise to use CFFI instead of the ALIEN (FFI) package of SBCL,
> since it's a portability layer that would allow you to change of Lisp
> implementation if the need appeared.)
>
> > That is in terms of scripting processes
>
> For scripting, I prefer clisp (smaller, and faster to load), but both
> clisp and sbcl can be run as #! "interpreters".
>
> > and flows and
> > in terms of doing system programming, like get a process that (for its
> > unix part) :
> > - open a device in /dev to regularly read a few kB of data,
>
> (with-open-file #| remember on unix devices are files! |#
> (input "/dev/urandom" :element-type '(unsigned-byte 8))
> (let ((kb (make-array 1024 :element-type '(unsigned-byte 8))))
> (dotimes (a-few (random 4))
> (read-sequence kb))))
>
> > - open a few pipes to exchange data with some processes,
> > - listen a socket to receive commands from another machine,
> > - launch and respond to a few seconds timer to write structures on
> > disk,
> > - finally multiplex all this i/o with a select syscall.
>
> All the above is possible in SBCL (and in the other implementations),
> but is implementation specific. The implementations provide different
> lisp API to do it, or you can use FFI to do it like in C.
>
>
> > Is it currently possible,
>
> Yes.
>
>
> > what are the limitations ?
>
> No different than in C.
>
>
> > If there are too many, would it be difficult (absurd, just a matter of
> > will and time...) to dive into SBCL/Linux and achieve this goal ?
>
> Not at all. Go ahead.
>
>
> > Thanks.
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> "You can tell the Lisp programmers. They have pockets full of punch
> cards with close parentheses on them." --> http://tinyurl.com/8ubpf
In addition to this, do you if there is a CL available which can do
asynchronous process control (ie. fork()/exec() and wait()/waitpid()),
or could this also be implemented via CFFI ?
Thanks,
Jurgen.
"jurgen_defurne" <··············@pandora.be> writes:
> In addition to this, do you if there is a CL available which can do
> asynchronous process control (ie. fork()/exec() and wait()/waitpid()),
> or could this also be implemented via CFFI ?
CLISP has Linux bindings:
[30]> (apropos :fork :linux)
LINUX:fork function
LINUX:vfork function
[31]> (apropos :wait :linux)
LINUX:wait function
LINUX:waitpid function
LINUX:SA_NOCLDWAIT constant
[32]> (apropos :exec :linux)
LINUX:execl function
LINUX:execl1 function
LINUX:execle1 function
LINUX:execlp function
LINUX:execlp1 function
LINUX:execv function
LINUX:execve function
LINUX:execvp function
LINUX:ELIBEXEC constant
LINUX:ENOEXEC constant
LINUX:FD_CLOEXEC constant
LINUX:S_IEXEC symbol-macro
And SBCL has POSIX bindings:
* (apropos :fork :sb-posix)
SB-POSIX:FORK (fbound)
* (apropos :exec :sb-posix)
SB-POSIX:ELIBEXEC (bound)
SB-POSIX:S-IEXEC (bound)
SB-POSIX:PROT-EXEC (bound)
SB-POSIX:ENOEXEC (bound)
* (apropos :wait :sb-posix)
SB-POSIX:WAITPID (fbound)
SB-POSIX:WAIT (fbound)
*
So that's one less thing to implement in CFFI.
Actually, one problem with FFIs in general, is that the API is defined
with some implicit data widths. You know, from the POSIX
specifications, that read(2) takes a size_t parameter, but you don't
know what it is exactly, 32-bit? 64-bit? To know that, you have to
process the C header files. The simpliest being to write a small C
program to print the size of size_t (and all the other types, and
offset in structures, etc). So, writting the correct and portable FFI
definitions is hard, and it's better to use the bindings provided by
the implementation, when they're available.
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Pascal Bourguignon wrote:
> "jurgen_defurne" <··············@pandora.be> writes:
>
> > In addition to this, do you if there is a CL available which can do
> > asynchronous process control (ie. fork()/exec() and wait()/waitpid()),
> > or could this also be implemented via CFFI ?
>
>
> CLISP has Linux bindings:
>
> [30]> (apropos :fork :linux)
> LINUX:fork function
> LINUX:vfork function
>
> [31]> (apropos :wait :linux)
> LINUX:wait function
> LINUX:waitpid function
> LINUX:SA_NOCLDWAIT constant
>
> [32]> (apropos :exec :linux)
> LINUX:execl function
> LINUX:execl1 function
> LINUX:execle1 function
> LINUX:execlp function
> LINUX:execlp1 function
> LINUX:execv function
> LINUX:execve function
> LINUX:execvp function
> LINUX:ELIBEXEC constant
> LINUX:ENOEXEC constant
> LINUX:FD_CLOEXEC constant
> LINUX:S_IEXEC symbol-macro
>
>
>
> And SBCL has POSIX bindings:
>
> * (apropos :fork :sb-posix)
>
> SB-POSIX:FORK (fbound)
> * (apropos :exec :sb-posix)
>
> SB-POSIX:ELIBEXEC (bound)
> SB-POSIX:S-IEXEC (bound)
> SB-POSIX:PROT-EXEC (bound)
> SB-POSIX:ENOEXEC (bound)
> * (apropos :wait :sb-posix)
>
> SB-POSIX:WAITPID (fbound)
> SB-POSIX:WAIT (fbound)
> *
>
>
> So that's one less thing to implement in CFFI.
>
>
>
> Actually, one problem with FFIs in general, is that the API is defined
> with some implicit data widths. You know, from the POSIX
> specifications, that read(2) takes a size_t parameter, but you don't
> know what it is exactly, 32-bit? 64-bit? To know that, you have to
> process the C header files. The simpliest being to write a small C
> program to print the size of size_t (and all the other types, and
> offset in structures, etc). So, writting the correct and portable FFI
> definitions is hard, and it's better to use the bindings provided by
> the implementation, when they're available.
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
> manner whatsoever, will increase the amount of disorder in the
> universe. Although no liability is implied herein, the consumer is
> warned that this process will ultimately lead to the heat death of
> the universe.
This is nice. I did not find these yet in the CLISP Implementation
Notes. This means that this brings Lisp one step closer to me for
replacing Perl (Perl being the language which has probably the most
features like Lisp, and having the largest library, with full and easy
to use bindings for processes and sockets :-).
jurgen_defurne wrote:
> Pascal Bourguignon wrote:
> > "jurgen_defurne" <··············@pandora.be> writes:
> >
> > > In addition to this, do you if there is a CL available which can do
> > > asynchronous process control (ie. fork()/exec() and wait()/waitpid()),
> > > or could this also be implemented via CFFI ?
> >
> >
> > CLISP has Linux bindings:
> >
> > [30]> (apropos :fork :linux)
> > LINUX:fork function
> > LINUX:vfork function
> >
> > [31]> (apropos :wait :linux)
> > LINUX:wait function
> > LINUX:waitpid function
> > LINUX:SA_NOCLDWAIT constant
> >
> > [32]> (apropos :exec :linux)
> > LINUX:execl function
> > LINUX:execl1 function
> > LINUX:execle1 function
> > LINUX:execlp function
> > LINUX:execlp1 function
> > LINUX:execv function
> > LINUX:execve function
> > LINUX:execvp function
> > LINUX:ELIBEXEC constant
> > LINUX:ENOEXEC constant
> > LINUX:FD_CLOEXEC constant
> > LINUX:S_IEXEC symbol-macro
> >
> >
> >
> > And SBCL has POSIX bindings:
> >
> > * (apropos :fork :sb-posix)
> >
> > SB-POSIX:FORK (fbound)
> > * (apropos :exec :sb-posix)
> >
> > SB-POSIX:ELIBEXEC (bound)
> > SB-POSIX:S-IEXEC (bound)
> > SB-POSIX:PROT-EXEC (bound)
> > SB-POSIX:ENOEXEC (bound)
> > * (apropos :wait :sb-posix)
> >
> > SB-POSIX:WAITPID (fbound)
> > SB-POSIX:WAIT (fbound)
> > *
> >
> >
> > So that's one less thing to implement in CFFI.
> >
> >
> >
> > Actually, one problem with FFIs in general, is that the API is defined
> > with some implicit data widths. You know, from the POSIX
> > specifications, that read(2) takes a size_t parameter, but you don't
> > know what it is exactly, 32-bit? 64-bit? To know that, you have to
> > process the C header files. The simpliest being to write a small C
> > program to print the size of size_t (and all the other types, and
> > offset in structures, etc). So, writting the correct and portable FFI
> > definitions is hard, and it's better to use the bindings provided by
> > the implementation, when they're available.
> >
> >
> > --
> > __Pascal Bourguignon__ http://www.informatimago.com/
> >
> > PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
> > manner whatsoever, will increase the amount of disorder in the
> > universe. Although no liability is implied herein, the consumer is
> > warned that this process will ultimately lead to the heat death of
> > the universe.
>
> This is nice. I did not find these yet in the CLISP Implementation
> Notes. This means that this brings Lisp one step closer to me for
> replacing Perl (Perl being the language which has probably the most
> features like Lisp, and having the largest library, with full and easy
> to use bindings for processes and sockets :-).
Oh, and a syntax which irritates me still after six years of
programming in Perl. That is why I prefer Lisp.
Jurgen
Pascal Bourguignon <···@informatimago.com> writes:
> Actually, one problem with FFIs in general, is that the API is defined
> with some implicit data widths. You know, from the POSIX
> specifications, that read(2) takes a size_t parameter, but you don't
> know what it is exactly, 32-bit? 64-bit? To know that, you have to
> process the C header files. The simpliest being to write a small C
> program to print the size of size_t (and all the other types, and
> offset in structures, etc). So, writting the correct and portable FFI
> definitions is hard, and it's better to use the bindings provided by
> the implementation, when they're available.
This is why SBCL has sb-grovel :-)
jurgen_defurne <··············@pandora.be> wrote:
+---------------
| In addition to this, do you if there is a CL available which can do
| asynchronous process control (ie. fork()/exec() and wait()/waitpid()),
| or could this also be implemented via CFFI ?
+---------------
Both SBCL and its ancestor CMUCL should have most of the standard
Unix [Posix, Linux] system calls in the "UNIX" package, e.g., I know
that CMUCL has UNIX:UNIX-FORK and UNIX:UNIX-EXECVE and lots more.
[UNIX:UNIX-WAIT & UNIX:UNIX-WAITPID are in "code/unix-glibc2.lisp",
but disabled. Why?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Christophe Rhodes
Subject: Re: SBCL and programming Linux
Date:
Message-ID: <sqbqqtt6zp.fsf@cam.ac.uk>
····@rpw3.org (Rob Warnock) writes:
> jurgen_defurne <··············@pandora.be> wrote:
> +---------------
> | In addition to this, do you if there is a CL available which can do
> | asynchronous process control (ie. fork()/exec() and wait()/waitpid()),
> | or could this also be implemented via CFFI ?
> +---------------
>
> Both SBCL and its ancestor CMUCL should have most of the standard
> Unix [Posix, Linux] system calls in the "UNIX" package, e.g., I know
> that CMUCL has UNIX:UNIX-FORK and UNIX:UNIX-EXECVE and lots more.
In SBCL, the analogue to CMUCL's UNIX package is not intended for use
by end-users, but contains only what is necessary to implement SBCL
(and its public extension). (Other people have already pointed to the
POSIX bindings for SBCL).
Christophe
Pascal Bourguignon a écrit :
> "Patrice Lespagnol" <·················@obs-nancay.fr> writes:
>
> > Hi,
> > Sorry my question is very SBCL oriented.
> > In more of being a good Common Lisp implementation (and, as I
> > understand it, speeding software prototyping and preventing to invent
> > the wheel again and again in C), is SBCL a good tool to deal with the
> > underlying unix ?
>
> SBCL has FFI, so you can do, unix wise, all you can do in C, in SBCL.
>
> (I'd advise to use CFFI instead of the ALIEN (FFI) package of SBCL,
> since it's a portability layer that would allow you to change of Lisp
> implementation if the need appeared.)
>
> > That is in terms of scripting processes
>
> For scripting, I prefer clisp (smaller, and faster to load), but both
> clisp and sbcl can be run as #! "interpreters".
>
> > and flows and
> > in terms of doing system programming, like get a process that (for its
> > unix part) :
> > - open a device in /dev to regularly read a few kB of data,
>
> (with-open-file #| remember on unix devices are files! |#
> (input "/dev/urandom" :element-type '(unsigned-byte 8))
> (let ((kb (make-array 1024 :element-type '(unsigned-byte 8))))
> (dotimes (a-few (random 4))
> (read-sequence kb))))
>
> > - open a few pipes to exchange data with some processes,
> > - listen a socket to receive commands from another machine,
> > - launch and respond to a few seconds timer to write structures on
> > disk,
> > - finally multiplex all this i/o with a select syscall.
>
> All the above is possible in SBCL (and in the other implementations),
> but is implementation specific. The implementations provide different
> lisp API to do it, or you can use FFI to do it like in C.
>
>
> > Is it currently possible,
>
> Yes.
>
>
> > what are the limitations ?
>
> No different than in C.
>
>
> > If there are too many, would it be difficult (absurd, just a matter of
> > will and time...) to dive into SBCL/Linux and achieve this goal ?
>
> Not at all. Go ahead.
>
>
> > Thanks.
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> "You can tell the Lisp programmers. They have pockets full of punch
> cards with close parentheses on them." --> http://tinyurl.com/8ubpf
OK, I'm convinced it will be a fructfull viewpoint on the road to
master SBCL. Thanks.
Also : I wonder what influence (constraint) garbage collection may
have had when you were using SBCL (or CLISP) for this kind of task ?
"Patrice Lespagnol" <·················@obs-nancay.fr> writes:
> Also : I wonder what influence (constraint) garbage collection may
> have had when you were using SBCL (or CLISP) for this kind of task ?
Garbage what?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
Pascal Bourguignon a écrit :
> "Patrice Lespagnol" <·················@obs-nancay.fr> writes:
>
> > Also : I wonder what influence (constraint) garbage collection may
> > have had when you were using SBCL (or CLISP) for this kind of task ?
>
> Garbage what?
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Un chat errant
> se soulage
> dans le jardin d'hiver
> Shiki
Sorry I mean : did you usualy have to bother about GC (ramasse-miette)
and the way it stops everything when you are doing system programming
with SBCL (or CLISP) ?
"Patrice Lespagnol" <·················@obs-nancay.fr> writes:
> Pascal Bourguignon a �crit :
>
>> "Patrice Lespagnol" <·················@obs-nancay.fr> writes:
>>
>> > Also : I wonder what influence (constraint) garbage collection may
>> > have had when you were using SBCL (or CLISP) for this kind of task ?
>>
>> Garbage what?
>
> Sorry I mean : did you usualy have to bother about GC (ramasse-miette)
> and the way it stops everything when you are doing system programming
> with SBCL (or CLISP) ?
This is an urban legend. Perhaps there was a time when you had to
wait five minutes for a garbage collection to complete, but that was
the time where the alternative was to put your card deck in a booth
and wait a day or two for the listing.
So, no, you don't bother about garbage collection.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
Pascal Bourguignon a écrit :
> "Patrice Lespagnol" <·················@obs-nancay.fr> writes:
>
> > Pascal Bourguignon a écrit :
> >
> >> "Patrice Lespagnol" <·················@obs-nancay.fr> writes:
> >>
> >> > Also : I wonder what influence (constraint) garbage collection may
> >> > have had when you were using SBCL (or CLISP) for this kind of task ?
> >>
> >> Garbage what?
> >
> > Sorry I mean : did you usualy have to bother about GC (ramasse-miette)
> > and the way it stops everything when you are doing system programming
> > with SBCL (or CLISP) ?
>
> This is an urban legend. Perhaps there was a time when you had to
> wait five minutes for a garbage collection to complete, but that was
> the time where the alternative was to put your card deck in a booth
> and wait a day or two for the listing.
>
> So, no, you don't bother about garbage collection.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
> technically be entitled to claim that this product is
> ten-dimensional. However, the consumer is reminded that this
> confers no legal rights above and beyond those applicable to
> three-dimensional objects, since the seven new dimensions are
> "rolled up" into such a small "area" that they cannot be
> detected.
To go further what's your opinion on using SBCL for soft real-time
programming, for example achieving to control events with a precision
of 10ms or so ?
In this circumstances what's the quality of SBCL's Alpha port (whose GC
sytem is more rudimentary) ?
"Patrice Lespagnol" <·················@obs-nancay.fr> writes:
> To go further what's your opinion on using SBCL for soft real-time
> programming, for example achieving to control events with a precision
> of 10ms or so ?
My opinion is that it should be easy to run a benchmark to evaluate
the usability of SBCL or any other implementation in such an
application. In particular, I guess that the generationnal garbage
collector of SBCL can help.
> In this circumstances what's the quality of SBCL's Alpha port (whose GC
> sytem is more rudimentary) ?
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
"Patrice Lespagnol" <·················@obs-nancay.fr> writes:
> Hi,
> Sorry my question is very SBCL oriented.
> In more of being a good Common Lisp implementation (and, as I
> understand it, speeding software prototyping and preventing to invent
> the wheel again and again in C), is SBCL a good tool to deal with the
> underlying unix ? That is in terms of scripting processes and flows and
> in terms of doing system programming, like get a process that (for its
> unix part) :
> - open a device in /dev to regularly read a few kB of data,
> - open a few pipes to exchange data with some processes,
> - listen a socket to receive commands from another machine,
> - launch and respond to a few seconds timer to write structures on
> disk,
> - finally multiplex all this i/o with a select syscall.
> Is it currently possible, what are the limitations ?
> If there are too many, would it be difficult (absurd, just a matter of
> will and time...) to dive into SBCL/Linux and achieve this goal ?
> Thanks.
Yes, SBCL is excellent for this. Alien is a nice FFI, plus a fairly
sophisticated sublanguage for handling C-style types. Sockets are
available from the sb-bsd-sockets system, most of POSIX is available
in sb-posix (and it's easy to add to if something's missing), and any
FD can be wrapped in a stream. Finally, SERVE-EVENT let's you do
painless select-style multiplexing.
> Yes, SBCL is excellent for this. Alien is a nice FFI, plus a fairly
> sophisticated sublanguage for handling C-style types. Sockets are
> available from the sb-bsd-sockets system, most of POSIX is available
> in sb-posix (and it's easy to add to if something's missing), and any
> FD can be wrapped in a stream. Finally, SERVE-EVENT let's you do
> painless select-style multiplexing.
Painless and select does IMHO can't be used in combination.
Does SBCL use kqueue on MacOSX or BSD's ?
"select" is the worst design error in Unix land.
llothar a écrit :
> > Yes, SBCL is excellent for this. Alien is a nice FFI, plus a fairly
> > sophisticated sublanguage for handling C-style types. Sockets are
> > available from the sb-bsd-sockets system, most of POSIX is available
> > in sb-posix (and it's easy to add to if something's missing), and any
> > FD can be wrapped in a stream. Finally, SERVE-EVENT let's you do
> > painless select-style multiplexing.
>
>
> Painless and select does IMHO can't be used in combination.
> Does SBCL use kqueue on MacOSX or BSD's ?
>
> "select" is the worst design error in Unix land.
What is your thought behind this assertion ?
> >
> > "select" is the worst design error in Unix land.
>
> What is your thought behind this assertion ?
Performance is getting absolutely worse if you have a few hunderts or
even thousands of file descriptors and if you have to wait for example
on filedescriptor no 1 and no 2450 then good night and good luck.
You might say that having 2450 files open is a design error then i tell
you it is not, BSD's and of course Windows can handle this well.
Resources for this are 320 KByte assuming 128 Byte of kernel memory for
an opened inode.
llothar wrote:
> Performance is getting absolutely worse if you have a few hunderts or
And forgot the maybe even more serious problem that you can only wait
for file descriptors but not System V IPC mechanisms like semaphors or
message queues and also not for pthread mechanisms like (dying)
threads, semaphors (again), condition variables.
And not to mention the signal handlers, dnotify on linux to track
modified directories.
And whats with asynchron callbacks aio.
Sorry "select" is the worst design error in the unix history.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: SBCL and programming Linux
Date:
Message-ID: <878xlswmfg.fsf@qrnik.zagroda>
"llothar" <·······@web.de> writes:
> You might say that having 2450 files open is a design error then i tell
> you it is not, BSD's and of course Windows can handle this well.
Linux too, but you should use epoll() instead of select().
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
llothar wrote:
>>Yes, SBCL is excellent for this. Alien is a nice FFI, plus a fairly
>>sophisticated sublanguage for handling C-style types. Sockets are
>>available from the sb-bsd-sockets system, most of POSIX is available
>>in sb-posix (and it's easy to add to if something's missing), and any
>>FD can be wrapped in a stream. Finally, SERVE-EVENT let's you do
>>painless select-style multiplexing.
>
>
>
> Painless and select does IMHO can't be used in combination.
> Does SBCL use kqueue on MacOSX or BSD's ?
>
> "select" is the worst design error in Unix land.
>
Using serve-event with SBCL *is* painless.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
"llothar" <·······@web.de> writes:
> > Yes, SBCL is excellent for this. Alien is a nice FFI, plus a fairly
> > sophisticated sublanguage for handling C-style types. Sockets are
> > available from the sb-bsd-sockets system, most of POSIX is available
> > in sb-posix (and it's easy to add to if something's missing), and any
> > FD can be wrapped in a stream. Finally, SERVE-EVENT let's you do
> > painless select-style multiplexing.
>
> Painless and select does IMHO can't be used in combination.
Good thing I said that SERVE-EVENT is painless, and I said "select-like".
> Does SBCL use kqueue on MacOSX or BSD's ?
>
> "select" is the worst design error in Unix land.
SERVE-EVENT lets you register handlers on FDs, and takes care of the
multiplexing itself. Exactly how it implements it is irrelevant at
this level of discussion, because the abstraction isn't leaky that way.