Arthur Bergman <[EMAIL PROTECTED]> wrote:
> Hi,
> Tracking down test failures in ponie I noticed some tests using SIGINT
> failing,
I'm using now SIGHUP for the tests. Hope that's ok.
> Arthur
leo
James Mastros <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
>>
>> Yeah. We're ultimately going to have to add signals to memory allocation
>> and IO as things that the embedding environment controls.
> Is it just me, or does this sound awful similar to the existing list of
> platform-dependent
Tim Bunce <[EMAIL PROTECTED]> wrote:
> We should distinguish between the Parrot core and the parrot
> executable command. The parrot executable command can use the
> extension interface to indicate that it wants signal handlers to
> be installed.
That can of course be separate. Anyway, if Ponie w
On Tue, Mar 16, 2004 at 08:43:11AM +, Arthur Bergman wrote:
> On 16 Mar 2004, at 06:36, Leopold Toetsch wrote:
> >But - as Dan did say - the plan for Parrot is to install signal
> >handlers by default.
We should distinguish between the Parrot core and the parrot
executable command. The parrot
Dan Sugalski wrote:
At 5:27 PM + 3/15/04, Arthur Bergman wrote:
No it doesn't, because an embedding environment might not want to let
parrot deal with signals, ever, and it might feel to restrict when it
sends them off. Signals are an environment issue and thus should be
controlled from the
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> On 16 Mar 2004, at 06:36, Leopold Toetsch wrote:
>>
>> This is a snipped from the stress example program I posted some days
>> ago
>> with an additional check if events are to be handled. Both functions
>> might not be in the extension interface[1].
>>
On 16 Mar 2004, at 06:36, Leopold Toetsch wrote:
This is a snipped from the stress example program I posted some days
ago
with an additional check if events are to be handled. Both functions
might not be in the extension interface[1].
Would it be possible to have a global variable that indicate
Jeff Clites <[EMAIL PROTECTED]> wrote:
> But anyway, I thought the call to Parrot_sigaction(SIGINT, ...) inside
> of Parrot_init_signals() was just for testing purposes anyway.
It's currently of course for testing only, w/o much usage or even
correctness, and it's linux only for now. But - as Dan
On Mar 15, 2004, at 9:30 AM, Dan Sugalski wrote:
At 5:27 PM + 3/15/04, Arthur Bergman wrote:
On 15 Mar 2004, at 17:25, Jeff Clites wrote:
We shouldn't, I would think, be snagging any signals unless user
code expresses an interest in the signal. The default disposition of
every signal is eit
At 5:27 PM + 3/15/04, Arthur Bergman wrote:
On 15 Mar 2004, at 17:25, Jeff Clites wrote:
We shouldn't, I would think, be snagging any signals unless user
code expresses an interest in the signal. The default disposition
of every signal is either to be ignored, or to abruptly terminate
the p
On 15 Mar 2004, at 17:25, Jeff Clites wrote:
We shouldn't, I would think, be snagging any signals unless user code
expresses an interest in the signal. The default disposition of every
signal is either to be ignored, or to abruptly terminate the process,
and we preserve that behavior if we just
On Mar 12, 2004, at 7:14 AM, Dan Sugalski wrote:
At 12:25 PM + 3/12/04, Arthur Bergman wrote:
Hi,
Tracking down test failures in ponie I noticed some tests using
SIGINT failing, they don't fail when I change the tests using
SIGUSR1, making me think that parrot somehow hijacks SIGINT but not
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dan Sugalski) wrote:
> At 12:25 PM + 3/12/04, Arthur Bergman wrote:
> >Hi,
> >
> >Tracking down test failures in ponie I noticed some tests using
> >SIGINT failing, they don't fail when I change the tests using
> >SIGUSR1, making me think t
At 12:25 PM + 3/12/04, Arthur Bergman wrote:
Hi,
Tracking down test failures in ponie I noticed some tests using
SIGINT failing, they don't fail when I change the tests using
SIGUSR1, making me think that parrot somehow hijacks SIGINT but not
other signals.
Is this per design or is it some
14 matches
Mail list logo
