On Sat, Jul 27, 2013 at 1:36 PM, Jonathan S. Shapiro <[email protected]>wrote:
> NoThreadSpawn - does not create any OS level threads >> > > If those threads survive to escape the call, it's an escape. If they are > all cleaned up before the thread is done, why is this any business of the > caller? What is the real-world concern? > The real-world concern is addressing issues in multi-threaded programming. Not all data structure designs are tolerant of arbitrary multi-threaded access, so any module which does multi-threaded callbacks could be an issue whether the threads outlive the call or not. The only threads we care less about are those which do not outlive the call *and* which can't send multi-threaded access into any non-thread-safe calls outside the module. > I can see uses for this. What I'm really trying to get at is whether this > wants to be an effect or whether the real thing we want is to be able to > type the fact that access to a given [graph of] object[s] is unique (i.e. > non-concurrent). > I hear you.. However, concurrent shared-memory programming is notoriously hard to get right, so I suspect any claims that code is concurrent-capable will often be erroneous. AFAIK, there is no automatic way to determine subsets of object graphs which are concurrent capable, since there can be arbitrary order dependencies even between data which has no pointer relationship. In practice, we manage this in systems more by knowing which code is concurrent, and which concurrent code calls which other code. BTW - I primarily find value in NoEscape per argument. I like C#'s ref semantics providing safe stack-argument passing of value-type-pointers. Rust's more general use of non-escaping borrowed pointer arguments enables a nice form of safe stack-bound block function pointer. I could imagine a similar construct being useful to assure region pointers do not escape the region, though I'm somewhat ignorant of region implementation so maybe there are other mechanisms for that. --- though that may all have been obvious. NoRingSwitch - does not call any kernel-call >> > > Again, why is this any business of the caller? What is the real-world > concern? > I was thinking generally about security and concurrency issues, either mechanisms by which the code might trigger a user-space stack-swap or interfere with stateful kernel processes which are not designed for concurrency (like stream pointers). Perhaps a more practical promise is that the code does not receive any signals/interrupts with callbacks out of the module, since this could be an out-of-band source of concurrency concerns. > NoBlock - does not call any blocking kernel calls >> > > I don't think this one is meaningful without NoPreempt. Can you give a > real-world use case? > IMO, this one is easy and clear. In async programming, we wish to explicitly avoid any calls which block. Accidentally using blocking calls in async loops is a HUGE source of bugs and performance problems. I not only want NoBlock declarations, but I also want a way to force a stack-scope to disallow any call to a non-NoBlock cal as a compiler error. I don't understand what you mean by NoPreempt, but I don't see how it would be related. Not quite. The only reason to preclude dependence on globals is isolation. > It is sufficient to preclude dependence on *mutable* globals. If *nobody* can > mutate a global, then that global is for all intents and purposes a > literal, and there's no real reason to be concerned about it. > Agreed. > Here's another potentially interesting one, thought the verification > system it implies is frightening: > > terminating - procedure, when called, is guaranteed to terminate > ...or the procedure has the potential to Exit() -- as opposed to throw an exception. I can see strong uses for several of these in very peculiar codes. Most of > them don't strike me as general enough to warrant promotion into > language-supported effects. Might be better to handle some of these with > attributes and an offline checker. > I'm not thinking about such distinctions. I'm thinking about what properties of code would it be useful to statically verify (and possibly even compiler-error on such as my NoBlock example), and further, be assured no future update to the module/dynamic-library violates this expectations.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
