アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
Re:今時の若いもの(藁)の意見 (スコア:1)
まず、ご存じないような感じがするのでirbの紹介
http://www.rubyist.net/~matz/?date=20030815
これを使ってUnixのコマンドを呼べばかなりのことができそうに感じます。
Windowsでしたら、ActiveScriptRubyをいれれば、一通り遊べます。
http://www.geocities.co.jp/SiliconValley-PaloAlto/9251/ruby/
もっとも、Rubyからでは標準出力と標準エラー出力を同時に取れなかったと思うため、
完璧なものではないでしょうけれども。
###
個人的に「UnixのOOラッパーとしてのRuby」という言い回し
Re:今時の若いもの(藁)の意見 (スコア:1)
や、俺もよく判っていません。
このmishimaさんの数年来のm(__)m日記を手繰って読んでるだけです。
#そういや、日記へのコメントのページから、作者の記事一覧ページへ、行けるリンクが無いような…>スラド
>まず、ご存じないような感じがするのでirbの紹介
>Windowsでしたら、ActiveScriptRubyをいれれば、一通り遊べます。
あう。名前は知っていますが使ったことが無いもんで言及しませんでした。
そういやLispつーかSchemeな人々が時折言ってますね、
「いっそLispをコマンドラインにしたらどうよ?」と。
#「やっぱり括弧がウザイかな?」とか(^^;
>もっとも、Rubyからでは標準出力と標準エラー出力を同時に取れなかったと思うため、
>完璧なものではないでしょうけれども。
まあ、1つのプロセスから互いにバラバラに出される2つの出力を、
また1つのプロセスで受けるのは、
(スレッドもselectも使わなければ)根本的に厄介な問題なので…
#以前知人が、そういうことをJavaでやろうとして、悶絶していたっけ…
てゆーか、そういう厄介が有るあたりに、
Pipe方式の部品化の未来の無さを感じてしまってます俺は。
部品化のことを考えたら、やっぱり、
実行主体(スレッドっていうか)は、オブジェクト(データ塊)とは、
へたに一対一対応に限定してしまわないほうが、よいんじゃないかと。
だいたい、Unixの(少なくとも現状の)シェルで楽にやれるリダイレクトだのパイプだのの範囲だと、
起動時に接続を決定せざるを得ず、後から切り替えることすら出来ない。
こんなもんが「部品化」と呼べるのか?ってのは、かなり疑問です。
UnixのあのPipeは、無数(?)にあるアーキテクチャパターンから見れば、
そのうちのほんの1つであるPipelineパターンをサポートしてるだけです。
しかも上記のようにHot切り替えも出来ない。駄目駄目です。
まあ、着脱できないものを無理矢理着脱可能にすることはそれなりに出来ます。
たとえばWindowシステムとOOPラッパーとの間でも、
Native Widgetより寿命が「長い」ラッパーを作ることで、
Native Widgetがサポートしてない変更を
(つまりNative Widgetを一旦捨てて作り直すことで)
変更可能に仕立ててしまう、なんてなことが出来ます。
でもまあそれは所謂「回避技術」であって、あまり前向きというかスッキリ感というかは乏しいなと。
>そうなったら、もはやRubyが何の上で動いているかは関係ないのかもしれません。
いや、「何を」ラップするのか?という問題が残ります。
たとえばUnixのselect「を」ラップしましたとか言われたら、他のOSはどうするのよ?とか。
頑張ればエミュレートは出来るかも知れないが効率悪そうだなとか。
#GUIアプリの「fork」が見てみたいのでG7
#やっぱり、同じ窓構成を持ったプロセス2つに「分身」するんでしょか?(藁
#便利なような、混乱のもとでしかないような?
##ついでに「exec」したらどうなるんだろ?
##窓の中身が「ぱっ」と別アプリに描き替わるの?(藁
###そういやリナザウだかで、C++ベースのアプリの起動の遅さをカバーするために、
###「途中まで起動」した状態のプロセスを眠らせといて、そいつをアプリ起動の要求に応じてforkする、
###っていう技術を使ってるとか聞いた気がしますが…
Re:今時の若いもの(藁)の意見 (スコア:1)
> 起動時に接続を決定せざるを得ず、後から切り替えることすら出来ない。
> こんなもんが「部品化」と呼べるのか?ってのは、かなり疑問です。
同意。
一番必要なのはその部分だと思ってます。
ま、着脱用の処理をするプロセスを一個はさんで
無理矢理着脱可能にしちゃえばいいと思ってるのですが。
(統一的にそういうものを扱うツールというのがいままで Unix に
なかったのが不思議)
> #GUIアプリの「fork」が見てみたいのでG7
> #やっぱり、同じ窓構成を持ったプロセス2つに「分身」するんでしょか?(藁
> #便利なような、混乱のもとでしかないような?
いわゆる GUI アプリって、変な構造ですよね。
「いまどんな画面を表示しているか?」ということが重要なのに、
その「状態」がメモリ上にしかなくて保存することが難しい。
そのくせバグが多くてよく落ちる。そうすると最初からやり直し。
GUI アプリであっても、Web アプリであれば状態は DB サーバに
格納できたりして被害はぐんと小さくなる。
これだと fork の意味がはっきりしてくるように思うわけですが。
(ブラウザのウィンドウの複製か、DB のデータの複製か)
# mishimaは本田透先生を熱烈に応援しています
Re:今時の若いもの(藁)の意見 (スコア:1)
>無理矢理着脱可能にしちゃえばいいと思ってるのですが。
Unixのプロセスの管理形態とパイプとの関連性って、どうなってるんでしたっけ。
すみません、いまだによく判ってなくて。
つまり、親子関係だったかな?という話です。
Unixのプロセスって親子関係の縛りがキツイですよね。
親子関係自体を自由自在に乗り換えれるといいんでしょうけど、なんかそうじゃないようで。
つまり着脱をOSのアーキテクチャが許してくれるかな?という話です。どうでしたっけ?
OOPの場合は、基本的に親子関係なんてものはアテにしない、
ネットワーク(通信という意味じゃなく多対多という意味の)モデルです。
だからどうとでも繋がり得る。
C言語で喩える(藁)と、Auto変数とmallocの違い。
結局、生成順序で縛ると、プログラムモデルの自由度が落ちる、というのが
OOP(というよりLisp)の慧眼なのでしょう。
そしてその際、廃棄モデルを、順序依存廃棄じゃなく参照切れ廃棄モデル(つまりGC)にする必要を見抜いた。
いっぽうUnixは、やっぱり、生成順序モデルの落とし子なんだと思います。
それで表現可能な範囲の仕事はエレガントにこなすけど、それ以上は困難だという。
#よく知らないんですが、たしかNamedPipeってのを使えば、この問題はかなりエレガントに解消できるんでしたよね。
#Pipeを着脱可能なパッチケーブルみたいに使えるっつー。
#…でもNamedなので名前空間(FileSystem)中の名前を消費するんでしたよね。
#これだと大量に使いたいときや動的に割り当てたいとき、名前の衝突を管理するという手間が増えて困る。
#つまりNamedPipe風だが無名なPipeを(しかももちろん一般ユーザ権限で)作るのが楽でないと困る。
#そして、もしそれを作っても、今度は無名のソレを誰がいつ解放責任を取るか?っていう問題が発生する。
#親プロセスが責任取るのか?でもそれじゃ結局親子問題が再燃だ。うーんうーん…
##つまり、「名前(ファイル名)とプロセスのどちらかを使ってしかPipeを束縛することが出来ない」のが問題なんだと思います。
##そしてこれは、PiepのみならずUnixのあらゆる面を支配してます。なにせUnixにはFileとProcessしか無い。
>いわゆる GUI アプリって、変な構造ですよね。
>「いまどんな画面を表示しているか?」ということが重要なのに、
>その「状態」がメモリ上にしかなくて保存することが難しい。
>そのくせバグが多くてよく落ちる。そうすると最初からやり直し。
保存については、Squeakみたいに記憶の一元化をするという手も有りますし、
BeOS(噂の又聞きですがたしか)みたいにアプリの状態保存をOS(とAPI)のネイティブな機能として盛り込む、という手もあります。
#ややこしいNetwork構造をFileとかに保存するアルゴリズムについては、
#JavaなりRubyなりでも最初からライブラリとして実装済みなので、心配無用。
てか、vi(m)だって-rがあるじゃないですか。
同じことをGUIアプリがやることは(原理的には)なんぼでも可能です。本質じゃない。
問題は、アプリ設計者(?)が、「何が状態なのか」をどう考えるか、って点だけです。つまり設計ね。
カーソル位置を保存するエディタと、しないエディタがある。その程度の差異です。
あと落ちるってのは今やデマでしょう。Winアプリも「OSが」9xまでは落ちましたが、
NT系だと vi(Unixの)が落ちるのと大差無い確率ですね。
リソース(Windows用語じゃなくメモリ含めた広い意味で)の管理が確かならば、
そうそう落ちないようですよ。
原理的に落ちやすいって訳ではなく足回りが腐ってるかどうかに依存するんだと思います。
まあイベント処理とかでデッドロックする恐れは有りますが(^^;
>GUI アプリであっても、Web アプリであれば状態は DB サーバに
>格納できたりして被害はぐんと小さくなる。
一昔前に業務アプリとして隆盛だったC/S方式でも、それは同じですね。
逆にいえばWebアプリ(の自分のセッションの鯖側)「が」落ちる(壊れる)恐れだって
ないわけじゃないんですし。
#特に今はアプリ作者の腕次第って場合も多い黎明期なんで、セッション壊しも有り得ない話じゃない。
Re:今時の若いもの(藁)の意見 (スコア:1)
G7 さんは SysV 系統のアプローチなんですな。
俺は BSD なアプローチの方が好みです。あくまで感覚的ですが。
結局のところ、プログラム開発ってのは複雑性の管理に他ならんわけです。
で、その複雑性を誰が面倒を見るか、という部分で
安定性=障害耐性や保守性、可用性、移植性、性能、開発効率
なんかが変わってくると。
Unix は「複雑なもの(=ファイル構造のネットワーク化とか)は
面倒見切れん、必要ならあとはユーザ空間で工夫してやれ」と
切り捨てたところがプロダクトとして最も良い部分でしょう。
そんな Unix も多少の拡張はあるわけですが、
利用者(=アプリ開発者)にとっての機能重視で拡張する
アプローチはどちらかといえば SysV 風、シンプルに実装側に
とって分かりやすい形で拡張するアプローチが BSD 風だと
(勝手に)思ってます。
> Unixのプロセスの管理形態とパイプとの関連性って、どうなってるんでしたっけ。
> つまり、親子関係だったかな?という話です。
そですね。名前つきパイプでない限りはそうなります。
名前つきパイプについてはその後 G7 さんが書かれたとおり。
> つまり着脱をOSのアーキテクチャが許してくれるかな?という話です。どうでしたっけ?
基本的には OS は許してくれません。必要ならユーザ空間で工夫してやれ、と。
そしてそれはそんなに難しい話ではないでしょう。
> #これだと大量に使いたいときや動的に割り当てたいとき、名前の衝突を管理するという手間が増えて困る。
> #つまりNamedPipe風だが無名なPipeを(しかももちろん一般ユーザ権限で)作るのが楽でないと困る。
まぁ現実的には「アプリケーション側にはパイプに見える
ストリームだけど、実は TCP or UNIX ソケットの接続でした」
とかいうアプローチで十分だと思いますよ。
自分の書いた「プロセスを一個はさめば着脱可能」ってのも
その方法で実装してます。
もし本物のパイプでやるとしても、BSD 的アプローチなら例えば
「プロセス ID ごとのディレクトリを作って、その中に作ればいいんだよ~!」
「名前がかぶったら .1, .2, .3, ... みたいな拡張子をつければいいんだよ~!」
とか答えるところ。
> #そして、もしそれを作っても、今度は無名のソレを誰がいつ解放責任を取るか?っていう問題が発生する。
> #親プロセスが責任取るのか?でもそれじゃ結局親子問題が再燃だ。うーんうーん…
これも、BSD 的アプローチなら
「cron で定期的に使われてなさげなパイプを削除するプログラムを動かせばいいんだよ~!」
とか答えるところです。
> 問題は、アプリ設計者(?)が、「何が状態なのか」をどう考えるか、って点だけです。つまり設計ね。
> カーソル位置を保存するエディタと、しないエディタがある。その程度の差異です。
ここで開発者側と利用者側の視点の差が出てしまうところが
(GUI に限らず) UI のもってる問題じゃないかなぁ。
開発者「テキストエディタの『状態』はファイルだろう」
利用者「どのファイルを編集しているか、だって重要な『状態』だよ!」
みたいな。
うーん、基本的に俺が考えているのが「小規模」「バグあり」
「ユーザサイド」なアプリを対象に、
「エンドユーザがプログラムの修正を簡単に行うためには」
「ゼロからの実装を簡単にするには」
「再設計無しに(または変更を最小限に)大規模まで拡張するには」
みたいなことだというのが自覚できたような気がします。
# mishimaは本田透先生を熱烈に応援しています
Re:今時の若いもの(藁)の意見 (スコア:1)
いや、別に俺は「拡張」したいわけではありません。
必要な機能は欲しいし、不要ならば要りません。それだけ。
それがUnixと重なってる部分が有るか無いかってのは
俺としては関心事から比較的遠いです。
例えばProcess壁とかは要らないと思ってますし。
理由は前述のとおり。Process間通信の"必要"性は、Object間通信のコストを増やすだけだから(^^;
余談ですが
バッファオーバーフロー攻撃などの昨今の頻出を見れば、
Process間にさえ壁を作ればいいというUnix風の「セキュリティ」モデルは、
野暮ったいんだろうと思います。
もっと小さい単位…たとえばStringとかArrayとか…の不正使用を抑止するほうが
余程大事なんじゃないかと。
よーするに鯖プログラムを全部Java(笑)とかに置き換えたらどうよ?と。
#もちろんCベースでもそれらを実現する手段が幾つか有るようなんですが、
#どうせCではそれ以外にも苦労が多いんで、どっかでまとめてリプレースしたいなあと。
#ExceptionとGCのない言語環境で「アプリ」を作るなんて、もう嫌です(T_T)
あと、C主義の限界ってのもありますね。 C主義ってのは、
(記憶が正しければK&R2の冒頭の宣言ですが)プログラマは何をするかを自分自身で判ってる、という前提
です。
一見正当な主張に聞こえますが、
OOPの多態とか、Callbackとか、Closureとか、GCとか、といったもの(の恩恵)を考えると、
なんでもプログラマ本人に責任取らせようとすると、却って「プログラムモデルが」煩雑になる、
という側面があるように感じています。
if文の洪水を自分で管理するより、Objectに管理させたほうが良い、とか。
メモリ解放の複雑怪奇な手順(複雑なデータ構造では複雑な解放が必要ですよね)を機械任せにする、とか。
以上のことはOSじゃなくライブラリが出来る仕事かも知れません。
ですが、Process壁みたいに、「邪魔」なものもカーネルには有るわけで、
それを外すところまで視野に入れたいです。
Unixも、べつに必ずしもシンプルってわけじゃないと思います。
壁作ったり、色々大変でしょう。
むしろUnixユーザのほうが、Unixの各種機能を最早空気のように意識してない(ので「シンプル」だと感じる)
というだけのことだったりしませんかね…
>基本的には OS は許してくれません。必要ならユーザ空間で工夫してやれ、と。
>そしてそれはそんなに難しい話ではないでしょう。
どんな工夫が要るかをちょっと考えたんですが、概念的には結構すごい換骨奪胎だったりしませんかね?
親子関係を無くすためのラッパーは結局、
「shell配下の全てのProcessはshell直下の子にする」
ことになるんじゃないかと思います。
そして、子Processのstdin/outをPipe(のようなもの)に接続しちゃう。
これで、shellは必要(?)に応じてPipe同士のつながり関係を替えちゃうことが出来るようになる。
で、問題は、shellがやらないとならない仕事が結構凄くなっちゃうんじゃないか?という点でして。
まずマルチスレッドでないとならないでしょうし
(それともselect()で足りるだろうか?…待てよ、selectって後から待ち受け数を増減できないですよね??)、
接続関係の変更の要求を子Processから(当然shellへ)投げるための手段も考えてあげないとならない。
あ。新たなProcessの生成の手段も違ってきますね。"自分の"子(つまりshellの孫)を作っては
イケナイんだから。まあそういうのはLocalProcessとでも呼べば良いのかも知れませんが。
あと、出力のmergeとかみたいに、もうちょっと気の利いた世界を目指すなら、どうすりゃいいか
っていう問題もあります。
Unixの出力データフォーマットは「構造化」されてないので、
mergeといっても単純にbyte(または行)単位で混ぜる羽目になる。
で、単純に混ぜちゃったら意味不明データにしかならないから、無価値。
無論、混ぜたものを後から分けるのも無理。
混ぜるっていうか、複数の流れを「同期」したいときが有ると思うんですが、
同期のための手段がアプリ依存では価値が低い。全アプリ共通であって欲しい。
でも今のままだとお手上げ。
#往年のMacのMidiManagerってのが参考になりそう。
#Midiアプリ同士をそれこそPipeで繋ぎまくれる。稼動中も切り替えできる。
#なんとご丁寧に、MIDI信号入出力だけじゃなく、同期のために同期信号入出力ってのも有り、これも繋ぎまくれる。
#ちなみにMacなのでGUIでサクサク切り替え可能。
#翻って、現状のUnixアプリには同期信号入出力は無いしなあ(^^;
#改行とかを検知して同期信号をでっち上げるラ
Re:今時の若いもの(藁)の意見 (スコア:1)
> いや、「何を」ラップするのか?という問題が残ります。
ここでラップするのはある目的を達成するための手段であって、例えばUnixのselectをラップするのとは違うかと。
ラッパーは当然selectに相当する処理は提供しますが、select自体は提供しない。
.NETからWin32APIを呼び出すようなものですから。
> GUIアプリの「fork」が見てみたいのでG7
IEの「新しいウィンドウで開く」とかはforkっぽいですかね。
> ついでに「exec」したらどうなるんだろ?
こちらはExplorerにURLいれたり、IEにファイルパスいれたり、でしょうか。
> そういやリナザウだかで、C++ベースのアプリの起動の遅さをカバーするために、
> 「途中まで起動」した状態のプロセスを眠らせといて、そいつをアプリ起動の要求に応じてforkする、
> っていう技術を使ってるとか聞いた気がしますが…
りなざうは持っていたり。。
確かにpsすると「高速起動」にしたアプリのプロセスが眠っているんですよね。
それをforkしていたんですか。
Re:今時の若いもの(藁)の意見 (スコア:1)
いや、例えばselectのような「考え方」をラップする、ってことは有ると思います。
例えば数年前のVersionまでのJava(あれもOSですよね?>Sun(藁))には
selectそのものどころか、select「的なもの」が何もなかったわけで。
#Threadを使えば、一応同じようなことは(非効率に)行なうことは出来るけど、そりゃ何か違うわけで。
APIって、大袈裟にいえばFrameworkなんです。
使い方のベストプラクティスから、時としてプログラム全体の考え方までをも、「縛る」ものです。
そう。考え方。
で、環境なりなんなりに、その「考え方」が最初から無い、ということはよく有るわけです。
#そういやMSX DOS1にはDirectoryが無かったなあ…(とおい目
>IEの「新しいウィンドウで開く」とかはforkっぽいですかね。
>こちらはExplorerにURLいれたり、IEにファイルパスいれたり、でしょうか。
あはは。あえて言えば似てますね。
そういう意味では、URL(色んな種類のメディアだのなんだのを飲み込んじゃえる)とか
それのレンダリングソフト(のPlatform)の実装としてのIE(とWindows)は、興味深いです。
でも逆にいえば、ああいう処でくらいしか見たことが無いんですよね。
他のアプリで、あんな挙動をする奴って、見たことが無い。
作れば当然出来るはずなんだけど。面白そうなんだけど。
>確かにpsすると「高速起動」にしたアプリのプロセスが眠っているんですよね。
>それをforkしていたんですか。
たしか、C++の仮想関数テーブルの解決を「実行ファイルが起動するたびに」やると、
その手間が馬鹿にならんので…という話だったとうろ覚えしてます。
確かに素晴らしい話なんですが、逆に言えば、
ここでもプロセスの壁とOOPとの相性の悪さが見え隠れしてるように思います。
この問題はたまたまforkで回避できたわけですが、ね…
Re:今時の若いもの(藁)の意見 (スコア:1)
「考え方」は「手段」のこと・・・ではないか、な。
ちょっとそこまで詰めきれてません、が、
UNIXselectの一挙手一投足をエミュレートするわけではない、ってことですかね。
Cygwinとは違う、と。
> APIって、大袈裟にいえばFrameworkなんです。
ですよね、ある種「言語」や「ライブラリ」と同種のものと捉えてます。
で、パラダイム自体がないというのは確かによくありますね。。。
ありがちなのが無名関数。
> 他のアプリで、あんな挙動をする奴って、見たことが無い。
使っている途中で、分身したり変身するソフト・・・他にないですねぇ。
デスクトップマスコットとかAgentとか呼ばれるソフトと組み合わせたら、
なにかおもしろいものができないかなぁ・・・。
> たしか、C++の仮想関数テーブルの解決を「実行ファイルが起動するたびに」やると、
> その手間が馬鹿にならんので…という話だったとうろ覚えしてます。
どうも、バッドノウハウの香りがしますね、、
プロセスの壁、が解決すればこれは大丈夫、と?
プロセスの壁って、その高さをメソッドの高さにまで下げればそれでいいのでしょうか。
#いや、メソッドじゃなくてインスタンスか・・・?
HTMLのフレームページで、上フレームのJavaScriptが、
下フレームのJavaScriptの変数にアクセスする感じですよね?
Re:今時の若いもの(藁)の意見 (スコア:1)
>「考え方」は「手段」のこと・・・ではないか、な。
考え方はWhatあたりだし、手段はHowだろう、と思います。
>> たしか、C++の仮想関数テーブルの解決を「実行ファイルが起動するたびに」やると、
>> その手間が馬鹿にならんので…という話だったとうろ覚えしてます。
>どうも、バッドノウハウの香りがしますね、、
ある意味でそうかも。
>プロセスの壁、が解決すればこれは大丈夫、と?
>
>プロセスの壁って、その高さをメソッドの高さにまで下げればそれでいいのでしょうか。
>#いや、メソッドじゃなくてインスタンスか・・・?
高さとかいうよりも、「どういう事象を」壁で遮るか?という問題だと思います。
まず、最悪暴走してもプロセスの外を侵さないってのは、
ポインタが抽象化されていれば(つまりポインタの演算なんてことの権利をアプリ(?)に与えなければ)
生じようが無くなる問題なので。
これは一連のモダン(?)なメモリ管理によって万事解決のはず。
似たような話として、バッファオーバーフロー云々もこれで解決かと。
あとはリソースのLimitの問題ですね。
「このプロセスには」メモリは幾つまで、ファイルは幾つまで、を許すとかいうアレ。
これ、素朴なOOPではサポートしていませんが、
Javaとかの中でもそういうLimitっぽい制約をかけるっていう研究は
なされてるみたいなんで、近い将来に期待ってとこかと。
あと、そもそもUnixスタイルだと、メモリの座(^^;としてはプロセスしか無い
ってのも、根本的に間違っているわけです。
実行ファイル(や動的ライブラリ)をメモリにロードしてから、ポインタを「解決」しておいた状態のモノが
必ずプロセスの中にしか置けないので、今みたいな変な話になる。
それはそれで別の身分を与えて、他のプログラム(?)から軽量な参照を許すようにすれば、いいわけで。
なお、いわゆる共有メモリでソレが出来るかどうかは存じません。
あとハードウェアによる”プロセス単位”のメモリ保護は、この場合は足枷でしかないってことで以下略。
>HTMLのフレームページで、上フレームのJavaScriptが、
>下フレームのJavaScriptの変数にアクセスする感じですよね?
アクセスPATHが有るかどうか、という話も関係してきますね。
PATHが有ればそれを不正に使う(故意かバグかはさておき)可能性も有るけど、
じゃあどこまで遮断しようか?と。
JavaServletのAPIでも、どっかの時点で、
"セッション"間のアクセスPATHを封じるようなAPI仕様変更が入ってた
と記憶してます。
結局プロセスの壁って、全て(?)のPATHが封鎖されちゃってるんですよね。だから困る。
必要な所だけ開けるってことをしとくと、だいぶ楽になるはず。
あと、権限を与える単位って、やっぱりスレッドか、それをまとめたもの(スレッドグループっていうのかなあ)
あたりになるのかも。