summaryrefslogtreecommitdiff
path: root/hurd/translator/discussion.mdwn
blob: 95f5ab0c2dc6ea4dd0fb283a9861955ce45d8006 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_documentation open_issue_hurd]]


# IRC, freenode, #hurd, 2011-08-25

    < frhodes> how can I replace an existing running server with a new one
      without rebooting?
    < antrik> frhodes: depends. if other critical things depend on it, you
      can't. there is no mechanism to serialize and pass on the open sessions
    < antrik> in some situations, you can orphan the old translator while
      starting a new one, so the previous clients will stay with the old one
      while new one will get the new one
    < antrik> obviously that only works for things that aren't exclusive by
      nature
    < antrik> in some cases, you might even be able simply to remove the old
      translator... but obviously only for non-critical stuff :-)


# IRC, freenode, #hurd, 2013-10-21

    <braunr> mhmm, there is a problem with thread destruction

[[open_issues/libpthread/t/fix_have_kernel_resources]].

    <braunr> actually, translator self destruction
    <braunr> if a request arrives after the last thread servicing a port set
      returns from mach_msg because of a timeout, but before the translator is
      detached from its parent, the client will get an error
    <braunr> it should very rarely happen, but if it does, we could face the
      same kind of issues we have when a server crashes
    <braunr> e.g. sshd looping over select() returning EBADF, consuming all cpu
    <braunr> not sure we want to introduce such new issues

    <braunr> i don't think i'll be able to make translators disappear reliably
      ..
    <braunr> but at least, thread consumption will correctly decrease with
      inactivity