Here you go:
https://bugs.openjdk.java.net/browse/JDK-8212828
If noone else steps in, I can sponsor the change for you.
Cheers, Thomas
On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote:
>
> Sure. I don't have any tracking information on the bugreport one I
> submitted, but if you can track tha
Sure. I don't have any tracking information on the bugreport one I
submitted, but if you can track that down and promote it, it would
save you some typing. Otherwise whatever you can do would be great,
thanks.
On Tue, Oct 23, 2018 at 9:02 AM Thomas Stüfe wrote:
>
> Oh, I can open a bug report on
Oh, I can open a bug report on JBS for you. Should I?
(Now I understand the "reuse bug id").
On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote:
>
> I've submitted a bug report via bugreport.java.com. If/when it gets
> promoted to a proper JIRA with an issue number, I'll see if I can put
> the
I've submitted a bug report via bugreport.java.com. If/when it gets
promoted to a proper JIRA with an issue number, I'll see if I can put
the patch up on jdk/submit.
On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote:
>
> The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process
> launching
* Thomas Stüfe:
>> The main problem for vfork in application code is that you need to *all*
>> disable signals, even signals used by the implementation. If a signal
>> handler runs by accident while the vfork is active, memory corruption is
>> practically guaranteed. The only way to disable the
Hi David,
On Mon, Oct 22, 2018 at 9:00 PM David Lloyd wrote:
>
> On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe wrote:
> > Hi all,
> [...]
> > So far I have not read a single technical reason in this thread why
> > vfork needs to be abandoned now
>
> Note that my patch does not abandon vfork. It
Hi Florian,
our mails crossed... I think I am fine now with posix_spawn(),
provided we do enough testing.
But I'll answer your questions inline.
On Mon, Oct 22, 2018 at 9:00 PM Florian Weimer wrote:
>
> * Thomas Stüfe:
>
> > So far I have not read a single technical reason in this thread why
>
I ran some tests on my local I ran a number of tests on various
machines and architectures, all with glibc variants older than 2.24,
and straced them, and they all used vfork() internally.
That made me curious, and I dug into the glibc sources and examined
the history. If I understand this correc
On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe wrote:
> Hi all,
[...]
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now
Note that my patch does not abandon vfork. It does not even change
the default exec strategy away from vfork, nor does it ca
* Thomas Stüfe:
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now - apart from it being obsolete. If you
> read my initial thread from September, you know that I think we have
> understood vfork's shortcomings very well, and that our (SAPs)
> p
Hi all,
First off, to be clear, I am certainly shedding no tears if I do not
get to contribute my vfork+exec*2 patch to upstream. It is a lot of
work, and I much rather do something else. However, I have spend too
much of my life with the Runtime.exec() layer to be easy about
changing it.
So far
* David Lloyd:
> Sure, but I don't really see this as necessary if glibc is already
> following the vfork-like path. Another thing to know is that at least
> in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag
> is completely ignored. See also [2].
Right, the manual pages are
On Sun, Oct 21, 2018 at 7:25 PM Martin Buchholz wrote:
> As author of the vfork strategy ... I'm supportive of the directions in this
> thread.
Great.
> vfork is even (!) less in favor than it used to be, so migrating off of it
> seems good. Just make sure we don't bring back the OOM problem
As author of the vfork strategy ...
I'm supportive of the directions in this thread.👍👍
David's patch seems like clear progress (although maybe now that we have
configure, we can make the spawn strategy conditional on HAVE_SPAWN_H)
vfork is even (!) less in favor than it used to be, so migrating o
Hi David,
On Fri, Oct 19, 2018 at 2:20 PM David Lloyd wrote:
>
> On Fri, Oct 19, 2018 at 1:56 AM Thomas Stüfe wrote:
> >
> > Hi David,
> >
> > (for convenience, here the old thread:
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html)
> >
> > I would rather not ex
On Fri, Oct 19, 2018 at 1:56 AM Thomas Stüfe wrote:
>
> Hi David,
>
> (for convenience, here the old thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html)
>
> I would rather not expose a third way to spawn to the end user. As a
> test switch for developers, thi
Hi David,
(for convenience, here the old thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html)
I would rather not expose a third way to spawn to the end user. As a
test switch for developers, this seems fine.
AFAIK (and someone please correct me if I am wrong)
The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process
launching on Linux, but it's the closest I could find out of what are
really a surprisingly large number of issues that refer to posix_spawn
in one way or another relating to ProcessImpl. There's a different
issue to move from vfork
18 matches
Mail list logo
