On Fri, Jan 14, 2011 at 2:25 PM, Matthew Mondor wrote:
> On Fri, 29 Oct 2010 23:56:33 +0200
> Juan Jose Garcia-Ripoll wrote:
> > a* The SIGINT handler always jumps to an outer point in the lisp code.
> > b* Similar as "a" but only when the function is marked interruptible.
> > c* Similar as "a" b
On Fri, 29 Oct 2010 23:56:33 +0200
Juan Jose Garcia-Ripoll wrote:
> Mathew, let me try to explain again what is the problem and a possible
> operation model.
[...]
Sorry for not having answered earlier, back when I received the message
I couldn't take the time to seriously read it and had placed
Mathew, let me try to explain again what is the problem and a possible
operation model.
First of all a reminder of how I name things (which may not be compatible
with usual standards :-). Compiled programs may receive "interrupts" or
"signals" which may be originated by the operating system or by
On Tue, Oct 26, 2010 at 5:54 PM, Waldek Hebisch wrote:
> I think it is reasonable to ignore POSIX restrictions. POSIX is mostly
> a C API standard, so it is affected by limitations of C library.
>
... which is what ECL uses internally! This is not SBCL, and even they do
not have everything under
>
> Beware, the following is a collection of confused ideas that pop up every
> few months. They all concern the way Lisp deals with interrupts and thread
> cancellation.
>
> Some background. Following SBCL we have fully supported process-kill and
> process-interrupt using signal handlers. Howeve
On Mon, 25 Oct 2010 22:09:14 +0200
Juan Jose Garcia-Ripoll wrote:
Since threads are not a standard part of CL, I'm rather confused about
what should be expected of implementations. POSIX threads are standard
however, and I have fair experience with them (I'll ask various
questions relatively to
On Mon, Oct 25, 2010 at 3:54 AM, Daniel Herring wrote:
> New APIs like signalfd are moving away from the random-interrupt model of
> signals towards a more I/O friendly model. See e.g.
> http://lwn.net/Articles/225714/
>
This is interesting, but as I said it is one of two possible views:
request
Two projects I couldn't remember earlier:
http://github.com/dgoncharov/libunixsignal
http://www.nongnu.org/libunwind/
> On Sun, 24 Oct 2010 21:54:33 -0400 (EDT)
> Daniel Herring wrote:
>
>> New APIs like signalfd are moving away from the random-interrupt model
>> of
>> signals towards a more I/O
On Sun, 24 Oct 2010 21:54:33 -0400 (EDT)
Daniel Herring wrote:
> New APIs like signalfd are moving away from the random-interrupt model of
> signals towards a more I/O friendly model. See e.g.
> http://lwn.net/Articles/225714/
This is interesting but also appears to be OS-specific... After a q
New APIs like signalfd are moving away from the random-interrupt model of
signals towards a more I/O friendly model. See e.g.
http://lwn.net/Articles/225714/
On Sun, 24 Oct 2010, Juan Jose Garcia-Ripoll wrote:
Beware, the following is a collection of confused ideas that pop up every few
mont
Beware, the following is a collection of confused ideas that pop up every
few months. They all concern the way Lisp deals with interrupts and thread
cancellation.
Some background. Following SBCL we have fully supported process-kill and
process-interrupt using signal handlers. However POSIX demands
11 matches
Mail list logo
