| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Revert "[perl #92828] eintr.t hangs on FreeBSD"
This reverts commit 6e59d93aee950461947904b4f24a7f52c6c85f58.
Revert "eintr.t: skip based on capability rather than OS"
This reverts commit df375c6d048b938ecdeaecc7b264a7f1a190120a.
My attempt to skip based on capability hung freebsd, and my attempt to fix
that failed. Give up for now.
|
| |
|
|
|
|
|
| |
My commit df375c6d048b938ecdeaecc7b264a7f1a190120a attempted to
convert t/io/eintr.t from OS-based skipping to capability-based skipping,
but it only tested whether reads from pipes are interruptible.
Some OSes (like FreeBSD) only hang on write; so probe for that too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The t/io/eintr.t tests require read/write system to calls to be
interruptible (to see if anything nasty can be done by the signal
handler).
Many platforms aren't interruptible, which means the tests would hang.
We currently work round this by skipping based on a hard-coded list of
OSes (such as win32, VMS etc).
Change this so that we instead do an initial test as to whether they are
interruptible, and if not, skip the whole test file.
|
| |
|
|
|
|
|
| |
We already skip this test file on many platforms which don't
have interruptible IO system calls. Extend this to unconditionally
skip if it's an even (production) release version, so that we don't get
false positives for other platforms we didn't know about.
|
| | |
|
| |
|
|
| |
(see tickets perl #85842 and #84688).
|
| |
|
|
|
|
|
|
|
| |
It appears that a larger PerlIO buffer combined with writing to a
pipe triggers an alternate write mechanism in FreeBSD called a
direct write, which is not interruptible by signals. That's
somewhat speculative and has not been confirmed by someone with
knowledge of FreeBSD internals, but we do know the test hangs, so
it's best not to run it for now.
|
| | |
|
| | |
|
| |
|
|
|
| |
Apperently it's causing smokers to hang, so skip until
I find out what's happening.
|
| |
|
|
|
|
|
|
| |
It's doing select() on a pipe, but only sockets work with select(),
and the read() on a pipe is not interruptible by an alarm. That's
probably because our pipe implementation is doing mailbox reads at
AST level but the alarm signal is also an AST and can't interrupt
another AST at the same mode.
|
|
|
Currently if an operation on a file handle is interrupted, and if
the signal handler accesses that same file handle (e.g. closes it),
then perl will crash. See [perl #75556].
This commit provides some basic infrastructure to avoid segfaults.
Basically it adds a lock count field to each handle (by re-purposing the
unused flags field in the PL_perlio array), then each time a signal
handler is called, the count is incremented. Then various parts of PerlIO
use a positive count to change behaviour. Most importantly, when layers
are popped, the PerlIOl structure is cleared, but not freed, and is left
in the chain of layers. This means that callers still holding pointers to
the various layers won't access freed structures. It does however mean
that PerlIOl structs may be leaked, and possibly slots in PL_perlio. But
this is better than crashing.
Not much has been done to give sensible behaviour on re-entrancy; for
example, a buffer that has already been written once might get written
again. Fixing this sort of thing would require a large-scale audit of
perlio.c.
|
